Re: PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422
Hi Michael, On Tue, Aug 30, 2016 at 10:32 AM, Anand Moon wrote: > Hi All > > Adding Vivek Gautam. Sorry for missing out this conversation. I am no longer part of Samsung. > > On 29 August 2016 at 16:35, Michael Niewöhner wrote: >> Hi Mathias, >> On Mo, 2016-08-29 at 13:59 +0300, Mathias Nyman wrote: >>> On 29.08.2016 10:28, Felipe Balbi wrote: >>> > >>> > >>> > Hi, >>> > >>> > Michael Niewöhner writes: >>> > > >>> > > [1.] One line summary of the problem: >>> > > DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422 >>> > > >>> > > [2.] Full description of the problem/report: >>> > > No usb 3.0 devices are being detected when attached while USB 2.0 >>> > > devices work on the same port. >>> > > USB 3.0 works after applying patches [9.1] and [9.2], but seems >>> > > to be >>> > > buggy. The usb hub is redetected every time an usb device is >>> > > attached. [snip] >>> > >>> > > >>> > > [9.] Other notes, patches, fixes, workarounds: >>> > > [9.1] https://lkml.org/lkml/2014/4/28/234 >>> > > [9.2] https://lkml.org/lkml/2015/2/2/259 These patches are required to get USB super-speed working on Exynos5420/5800. But they did not make to upstream. There was resistance on adding new phy_calibrate() callback. Without these patches the Exynos5420/5800 will enumerate all super-speed capable devices as high-speed devices. Last time we checked with exynos542x smdk boards and peach-* boards, we could get the Super - speed devices working. I have not tested odroid anytime so don't have much idea about the its intricacies. I guess Anand was able to use these patches to get his kernel working in past. When you have a downstream on-board usb hub, ideally it should be able to detect the devices and not reset everytime you connect a new device (like you mentioned earlier). There can be two possible reasons why the hub keeps getting reset ever after applying the above mentioned patches: 1) the clock rates are not proper. 2) the regulator load setting is not enough to drive the hub. Anand, can you please point Michael to an older kernel with which you could test usb on odroid successfully ? You can compare the clocks with an older version and see if there'a any difference. Any possibility of any other framework (such as, bus-freq) trimming down the clock - rates ? [snip] > > There are two dwc3 ports in the SoC : one for Gbit Ethernet another > one for on-board GL3521 USB 3.0 hub controller. > > 3.10.x kernel > odroid@odroid:~$ lsusb -t > /: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M > |__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M > /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M > /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M > |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 5000M > /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M > |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 480M > /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=exynos-ohci/3p, 12M > /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=s5p-ehci/3p, 480M > > 4.x kernel > odroid@odroid:~$ lsusb -t > /: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M > /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M > |__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 480M > /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M > |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 5000M > |__ Port 1: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M > |__ Port 2: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 5000M > /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M > |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 480M > /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=exynos-ohci/3p, 12M > /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=exynos-ehci/3p, 480M [snip] Michael, please paste the output of lsusb -t and/or lsusb -v as well. Best regards Vivek -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- 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] ARM64: dts: meson-gxbb-odroidc2: Enable USB Nodes
On 2016년 10월 01일 00:49, Kevin Hilman wrote:
> Brian Kim writes:
>
>> Enable both gxbb USB controller and add a 5V regulator for the OTG port
>> VBUS
>>
>> Signed-off-by: Brian Kim
> Thanks for the patch.
>
> In the future, please state what branch the patch should apply to when
> not using mainline. Because of the sd_emmc nodes in your patch, I could
> tell that it was based on my integ branch so was able to figure it out,
> but it's very helpful to maintainers if you state the branch and/or any
> dependencies explicity.
Okay, I will do next time.
I guessed the branch is your latest working branch by the commit logs.
>
>> ---
>> .../arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 29
>> ++
>> 1 file changed, 29 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
>> b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
>> index 8d89edc..997c671 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
>> @@ -64,6 +64,18 @@
>> reg = <0x0 0x0 0x0 0x8000>;
>> };
>>
>> +usb_pwr: regulator-usb-pwrs {
> minor nit: since this is specific to the OTG part, can you call this
> usb_otg_pwr? ...
Sure.
>
>> +compatible = "regulator-fixed";
>> +
>> +regulator-name = "USB_PWR";
> ... and rename this also?
Yes, I will change the name to "USB_OTG_PWR".
>
>> +regulator-min-microvolt = <500>;
>> +regulator-max-microvolt = <500>;
>> +
>> +gpio = <&gpio_ao GPIOAO_5 GPIO_ACTIVE_HIGH>;
>> +enable-active-high;
>> +};
>> +
> Thanks
>
> Kevin
>
--
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: gadget: f_fs: stop sleeping in ffs_func_eps_disable
On Mon, Oct 3, 2016 at 5:07 PM, Michal Nazarewicz wrote:
> ffs_func_eps_disable is called from atomic context so it cannot sleep
> thus cannot grab a mutex. Change the handling of epfile->read_buffer
> to use non-sleeping synchronisation method.
>
> Reported-by: Chen Yu
> Signed-off-by: Michał Nazarewicz
> Fixes: 9353afbbfa7b ("buffer data from ‘oversized’ OUT requests")
> Tested-by: Chen Yu
> ---
> drivers/usb/gadget/function/f_fs.c | 109
> +++--
> 1 file changed, 93 insertions(+), 16 deletions(-)
>
> Compared to the previous version:
> • this one has a bit more comments (I feel like it’s a bad sign that
> this needs so much documentation);
> • ffs_epfile_realese sets read_buffer to READ_BUFFER_DROP (which
> doesn’t matter since on entry __ffs_epfile_read_buffered behaves
> the same way when read_buffer is NULL or READ_BUFFER_DROP); and
> • __ffs_epfile_read_data will drop the temporary data if read_buffer
> is READ_BUFFER_DROP (which may happen if ep is disabled between ep
> request finishes and data is copied to user space).
>
> Chen, John, if you could test this version as well, that would be
> swell.
for both patches:
Tested-by: John Stultz
Thanks so much for these!
-john
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] usb: gadget: f_fs: edit epfile->ep under lock
epfile->ep is protected by ffs->eps_lock (not epfile->mutex) so clear it
while holding the spin lock.
Signed-off-by: Michal Nazarewicz
---
drivers/usb/gadget/function/f_fs.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/function/f_fs.c
b/drivers/usb/gadget/function/f_fs.c
index 0aeed85..759f5d4 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -1725,17 +1725,17 @@ static void ffs_func_eps_disable(struct ffs_function
*func)
unsigned long flags;
do {
- if (epfile)
- mutex_lock(&epfile->mutex);
spin_lock_irqsave(&func->ffs->eps_lock, flags);
/* pending requests get nuked */
if (likely(ep->ep))
usb_ep_disable(ep->ep);
++ep;
+ if (epfile)
+ epfile->ep = NULL;
spin_unlock_irqrestore(&func->ffs->eps_lock, flags);
if (epfile) {
- epfile->ep = NULL;
+ mutex_lock(&epfile->mutex);
kfree(epfile->read_buffer);
epfile->read_buffer = NULL;
mutex_unlock(&epfile->mutex);
--
2.8.0.rc3.226.g39d4020
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] usb: gadget: f_fs: stop sleeping in ffs_func_eps_disable
ffs_func_eps_disable is called from atomic context so it cannot sleep
thus cannot grab a mutex. Change the handling of epfile->read_buffer
to use non-sleeping synchronisation method.
Reported-by: Chen Yu
Signed-off-by: Michał Nazarewicz
Fixes: 9353afbbfa7b ("buffer data from ‘oversized’ OUT requests")
Tested-by: Chen Yu
---
drivers/usb/gadget/function/f_fs.c | 109 +++--
1 file changed, 93 insertions(+), 16 deletions(-)
Compared to the previous version:
• this one has a bit more comments (I feel like it’s a bad sign that
this needs so much documentation);
• ffs_epfile_realese sets read_buffer to READ_BUFFER_DROP (which
doesn’t matter since on entry __ffs_epfile_read_buffered behaves
the same way when read_buffer is NULL or READ_BUFFER_DROP); and
• __ffs_epfile_read_data will drop the temporary data if read_buffer
is READ_BUFFER_DROP (which may happen if ep is disabled between ep
request finishes and data is copied to user space).
Chen, John, if you could test this version as well, that would be
swell.
diff --git a/drivers/usb/gadget/function/f_fs.c
b/drivers/usb/gadget/function/f_fs.c
index 759f5d4..e15fc1b 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -136,8 +136,60 @@ struct ffs_epfile {
/*
* Buffer for holding data from partial reads which may happen since
* we’re rounding user read requests to a multiple of a max packet size.
+*
+* The pointer is initialised with NULL value and may be set by
+* __ffs_epfile_read_data function to point to a temporary buffer.
+*
+* In normal operation, calls to __ffs_epfile_read_buffered will consume
+* data from said buffer and eventually free it. Importantly, while the
+* function is using the buffer, it sets the pointer to NULL. This is
+* all right since __ffs_epfile_read_data and __ffs_epfile_read_buffered
+* can never run concurrently (they are synchronised by epfile->mutex)
+* so the latter will not assign a new value to the pointer.
+*
+* Meanwhile ffs_func_eps_disable frees the buffer (if the pointer is
+* valid) and sets the pointer to READ_BUFFER_DROP value. This special
+* value is crux of the synchronisation between ffs_func_eps_disable and
+* __ffs_epfile_read_data.
+*
+* Once __ffs_epfile_read_data is about to finish it will try to set the
+* pointer back to its old value (as described above), but seeing as the
+* pointer is not-NULL (namely READ_BUFFER_DROP) it will instead free
+* the buffer.
+*
+* == State transitions ==
+*
+* • ptr == NULL: (initial state)
+* ◦ __ffs_epfile_read_buffer_free: go to ptr == DROP
+* ◦ __ffs_epfile_read_buffered:nop
+* ◦ __ffs_epfile_read_data allocates temp buffer: go to ptr == buf
+* ◦ reading finishes: n/a, not in ‘and reading’ state
+* • ptr == DROP:
+* ◦ __ffs_epfile_read_buffer_free: nop
+* ◦ __ffs_epfile_read_buffered:go to ptr == NULL
+* ◦ __ffs_epfile_read_data allocates temp buffer: free buf, nop
+* ◦ reading finishes: n/a, not in ‘and reading’ state
+* • ptr == buf:
+* ◦ __ffs_epfile_read_buffer_free: free buf, go to ptr == DROP
+* ◦ __ffs_epfile_read_buffered:go to ptr == NULL and reading
+* ◦ __ffs_epfile_read_data:n/a, __ffs_epfile_read_buffered
+*is always called first
+* ◦ reading finishes: n/a, not in ‘and reading’ state
+* • ptr == NULL and reading:
+* ◦ __ffs_epfile_read_buffer_free: go to ptr == DROP and reading
+* ◦ __ffs_epfile_read_buffered:n/a, mutex is held
+* ◦ __ffs_epfile_read_data:n/a, mutex is held
+* ◦ reading finishes and …
+* … all data read: free buf, go to ptr == NULL
+* … otherwise: go to ptr == buf and reading
+* • ptr == DROP and reading:
+* ◦ __ffs_epfile_read_buffer_free: nop
+* ◦ __ffs_epfile_read_buffered:n/a, mutex is held
+* ◦ __ffs_epfile_read_data:n/a, mutex is held
+* ◦ reading finishes: free buf, go to ptr == DROP
*/
- struct ffs_buffer *read_buffer; /* P: epfile->mutex */
+ struct ffs_buffer *read_buffer;
+#define READ_BUFFER_DROP ((struct ffs_buffer *)ERR_PTR(-ESHUTDOWN))
charname[5];
@@ -736,25 +788,47 @@ static void ffs_epfile_async_io_complete(struct usb_ep
*_ep,
schedule_work(&io_data->work);
}
+static void __ffs_epfile_read_buffer_free(struct ffs_epfile *epfile)
+{
+ /*
+* See comment in struct ffs_epfile for full read_bu
Re: BUG: scheduling while atomic in f_fs when gadget remove driver
On Mon, Oct 3, 2016 at 1:16 PM, John Stultz wrote: > On Mon, Oct 3, 2016 at 1:07 PM, Michal Nazarewicz wrote: >> On Mon, Oct 03 2016, John Stultz wrote: >>> Can you resend it using git-send-email or in some way other then >>> embedding it inline here? Maybe just point me to a git tree that has >>> it? >> >> https://github.com/mina86/linux.git f-fs-fix > > Thanks so much! I'll fetch that and get testing on my side with it as well! Thanks! Looking good on my side as well, so for both of those changes (if its helpful): Tested-by: John Stultz thanks -john -- 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] ORICO 2588US3 USB HDD enclosure goes offline after idle
Hi Oliver, Sorry for the late reply. Installing the custom kernel (and making it boot) turned out to be the hard part for me. On 12.09.2016 15:03, Oliver Neukum wrote: please try: scsi_logging_level -s -E 7 I've applied the patch and booted with the modified kernel. It did disable LPM for this device (usb3_hardware_lpm_u1 and usb3_hardware_lpm_u2 do not exist). Subjectively, it seemed like it took a few minutes longer this time for the drive to start failing, but I didn't do a strict comparison. The related dmesg output attached. I've also tried emailing Orico's support about this issue (asking for newer firmware that supports UASP). Their reply is below: """ Dear customer Thanks for your contacting us and so honor to serve you I am sorry that item have not UASP function and cannot support Firmware refresh Thanks a lot Best Regards Maite ORICO Technologies Co.,Ltd ma...@orico.com.cn www.orico.com.cn F-12, Building 8, Xincheng Science &Technology City, Lugu, Yuelu, Changsha, China """ Best regards, Dmitry. [ 136.365195] usb 2-1: new SuperSpeed USB device number 3 using xhci_hcd [ 136.382307] usb 2-1: New USB device found, idVendor=357d, idProduct=7788 [ 136.382315] usb 2-1: New USB device strings: Mfr=10, Product=11, SerialNumber=3 [ 136.382320] usb 2-1: Product: USB to ATA/ATAPI Bridge [ 136.382324] usb 2-1: Manufacturer: JMicron [ 136.382327] usb 2-1: SerialNumber: 12345678 [ 136.415261] usbcore: registered new interface driver usb-storage [ 136.417107] scsi host3: scsi_eh_3: sleeping [ 136.417694] scsi host3: uas [ 136.417821] usbcore: registered new interface driver uas [ 136.419284] scsi 3:0:0:0: Direct-Access ST1000LM 024 HN-M101MBB 0100 PQ: 0 ANSI: 6 [ 136.422280] sd 3:0:0:0: Attached scsi generic sg0 type 0 [ 136.422850] sd 3:0:0:0: [sda] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB) [ 136.422852] sd 3:0:0:0: [sda] 4096-byte physical blocks [ 136.425891] sd 3:0:0:0: [sda] Write Protect is off [ 136.425894] sd 3:0:0:0: [sda] Mode Sense: 67 00 10 08 [ 136.427067] sd 3:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA [ 136.427759] sd 3:0:0:0: scsi_block_when_processing_errors: rtn: 1 [ 136.465070] sda: sda1 [ 136.465413] sd 3:0:0:0: scsi_block_when_processing_errors: rtn: 1 [ 136.470902] sd 3:0:0:0: [sda] Attached SCSI disk [ 136.475674] sd 3:0:0:0: scsi_block_when_processing_errors: rtn: 1 [ 136.476834] sd 3:0:0:0: scsi_block_when_processing_errors: rtn: 1 [ 136.476838] sd 3:0:0:0: scsi_block_when_processing_errors: rtn: 1 [ 136.476840] sd 3:0:0:0: scsi_block_when_processing_errors: rtn: 1 [ 136.477494] sd 3:0:0:0: scsi_block_when_processing_errors: rtn: 1 [ 136.477495] sd 3:0:0:0: scsi_block_when_processing_errors: rtn: 1 [ 136.483845] sd 3:0:0:0: scsi_block_when_processing_errors: rtn: 1 [ 136.483921] sd 3:0:0:0: scsi_block_when_processing_errors: rtn: 1 [ 136.485505] sd 3:0:0:0: scsi_block_when_processing_errors: rtn: 1 [ 136.485687] sd 3:0:0:0: scsi_block_when_processing_errors: rtn: 1 [ 136.615014] sd 3:0:0:0: scsi_block_when_processing_errors: rtn: 1 [ 136.627689] sd 3:0:0:0: scsi_block_when_processing_errors: rtn: 1 [ 136.628554] sd 3:0:0:0: scsi_block_when_processing_errors: rtn: 1 [ 136.631632] sd 3:0:0:0: scsi_block_when_processing_errors: rtn: 1 [ 136.757473] sd 3:0:0:0: scsi_block_when_processing_errors: rtn: 1 [ 136.757569] sd 3:0:0:0: scsi_block_when_processing_errors: rtn: 1 [ 136.758785] sd 3:0:0:0: scsi_block_when_processing_errors: rtn: 1 [ 136.761184] sd 3:0:0:0: scsi_block_when_processing_errors: rtn: 1 [ 136.885728] sd 3:0:0:0: scsi_block_when_processing_errors: rtn: 1 [ 136.919411] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) [ 1176.531682] sd 3:0:0:0: [sda] tag#0 abort scheduled [ 1176.539676] sd 3:0:0:0: [sda] tag#0 aborting command [ 1176.539689] sd 3:0:0:0: [sda] tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN [ 1176.539696] sd 3:0:0:0: [sda] tag#0 CDB: Read(10) 28 00 34 de 91 e0 00 01 00 00 [ 1176.539858] sd 3:0:0:0: [sda] tag#0 cmd abort failed [ 1179.475757] sd 3:0:0:0: [sda] tag#1 not aborting, host in recovery [ 1206.548061] sd 3:0:0:0: [sda] tag#2 not aborting, host in recovery [ 1206.548071] sd 3:0:0:0: [sda] tag#3 not aborting, host in recovery [ 1206.548076] sd 3:0:0:0: [sda] tag#4 not aborting, host in recovery [ 1206.548080] sd 3:0:0:0: [sda] tag#5 not aborting, host in recovery [ 1206.548085] sd 3:0:0:0: [sda] tag#6 not aborting, host in recovery [ 1206.548089] sd 3:0:0:0: [sda] tag#7 not aborting, host in recovery [ 1206.548093] sd 3:0:0:0: [sda] tag#8 not aborting, host in recovery [ 1206.548097] sd 3:0:0:0: [sda] tag#9 not aborting, host in recovery [ 1206.548101] sd 3:0:0:0: [sda] tag#10 not aborting, host in recovery [ 1206.548106] sd 3:0:0:0: [sda] tag#11 not aborting, host in recovery [ 1206.548110] sd 3:0:0:0: [sda] tag#12 not aborting, host in recovery [ 1206.548114] sd 3:0:0:0: [sda] tag#13 not aborting, ho
[RFC v4 1/2] usb: typec: USB Type-C Port Manager (tcpm)
This driver implements the USB Type-C Power Delivery state machine for both source and sink ports. Alternate mode support is not fully implemented. The driver attaches to the USB Type-C class code implemented in the following patches. usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C PHY usb: USB Type-C connector class This driver only implements the state machine. Lower level drivers are responsible for - Reporting VBUS status and activating VBUS - Setting CC lines and providing CC line status - Setting line polarity - Activating and deactivating VCONN - Setting the current limit - Activating and deactivating PD message transfers - Sending and receiving PD messages The driver provides both a functional API as well as callbacks for lower level drivers. Signed-off-by: Guenter Roeck --- v4: - Source and sink capabilities can now change on the fly - Introduced several new macros to identify CC states - Determine RP value to set based on maximum current supported by a port configured as source - Support for DRP toggling implemented in hardware (by Type-C port controller) - Added MODULE_ macros v3: - Improve TCPM state machine resiliency if there are spurious CC line changes while the state machine is in a transient change (waiting for a timeout) - Update current limit after CC voltage level changes on a port which is not PD capable. v2: - Only update polarity if setting it was successful If setting the CC line polarity in the driver was not successful, don't update the internal polarity state. - All PD messages are little endian; convert to and from CPU endianness. - Avoid comparisons against NULL. - Use u8/u16/u32 instead of uint8_t/uint16_t/uint32_t consistently. - Callbacks into tcpm need to be lockless to avoid timing problems in low level drivers. - Simplify callbacks; tcpm can request the current state of cc/vbus when it is ready to use it. drivers/usb/typec/Kconfig |7 + drivers/usb/typec/Makefile |1 + drivers/usb/typec/tcpm.c | 3335 drivers/usb/typec/tcpm.h | 148 ++ include/linux/usb/pd.h | 281 include/linux/usb/pd_bdo.h | 31 + include/linux/usb/pd_vdo.h | 412 ++ 7 files changed, 4215 insertions(+) create mode 100644 drivers/usb/typec/tcpm.c create mode 100644 drivers/usb/typec/tcpm.h create mode 100644 include/linux/usb/pd.h create mode 100644 include/linux/usb/pd_bdo.h create mode 100644 include/linux/usb/pd_vdo.h diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig index 7a345a4b1e7a..113bb1b3589c 100644 --- a/drivers/usb/typec/Kconfig +++ b/drivers/usb/typec/Kconfig @@ -18,4 +18,11 @@ config TYPEC_WCOVE To compile this driver as module, choose M here: the module will be called typec_wcove +config TYPEC_TCPM + tristate "USB Type-C Port Controller Manager" + select TYPEC + help + The Type-C Port Controller Manager provides a USB PD and USB Type-C + state machine for use with Type-C Port Controllers. + endmenu diff --git a/drivers/usb/typec/Makefile b/drivers/usb/typec/Makefile index b9cb862221af..bbe45721cf52 100644 --- a/drivers/usb/typec/Makefile +++ b/drivers/usb/typec/Makefile @@ -1,2 +1,3 @@ obj-$(CONFIG_TYPEC)+= typec.o obj-$(CONFIG_TYPEC_WCOVE) += typec_wcove.o +obj-$(CONFIG_TYPEC_TCPM) += tcpm.o diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c new file mode 100644 index ..0bc36685ad02 --- /dev/null +++ b/drivers/usb/typec/tcpm.c @@ -0,0 +1,3335 @@ +/* + * Copyright 2015-2016 Google, Inc + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * USB Power Delivery protocol stack. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "tcpm.h" + +#define FOREACH_STATE(S) \ + S(INVALID_STATE), \ + S(DRP_TOGGLING),\ + S(SRC_UNATTACHED), \ + S(SRC_ATTACH_WAIT), \ + S(SRC_ATTACHED),\ + S(SRC_STARTUP), \ + S(SRC_SEND_CAPABILITIES), \ + S(SRC_NEGOTIATE_CAPABILITIES), \ + S(SRC_TRANSITION_SUPPLY), \ + S(SRC_READY), \ + S(SRC_WAIT_NEW_CAPABILITIES), \ +
[RFC v4 2/2] usb: typec: Type-C Port Controller Interface driver (tcpci)
The port controller interface driver interconnects the Type-C Port
Manager with a Type-C Port Controller Interface (TCPCI) compliant
port controller.
Signed-off-by: Guenter Roeck
---
v4:
- Fix RP value set for ports supporting 3A current
- Implement support for DRP toggling in hardware
- When setting VBUS, disable both source and sink before enabling anything
- Set correct byte count in tcpci_pd_transmit()
- Disable chip interrupts before registering interrupt handler
- Request IRQF_ONESHOT | IRQF_TRIGGER_LOW instead of IRQF_TRIGGER_FALLING
v3:
- No change
v2:
- Adjust to modified callbacks into tcpm code
drivers/usb/typec/Kconfig | 9 +
drivers/usb/typec/Kconfig | 9 +
drivers/usb/typec/Makefile | 1 +
drivers/usb/typec/tcpci.c | 529 +
drivers/usb/typec/tcpci.h | 133
4 files changed, 672 insertions(+)
create mode 100644 drivers/usb/typec/tcpci.c
create mode 100644 drivers/usb/typec/tcpci.h
diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
index 113bb1b3589c..a92c9d1a3e00 100644
--- a/drivers/usb/typec/Kconfig
+++ b/drivers/usb/typec/Kconfig
@@ -25,4 +25,13 @@ config TYPEC_TCPM
The Type-C Port Controller Manager provides a USB PD and USB Type-C
state machine for use with Type-C Port Controllers.
+if TYPEC_TCPM
+
+config TYPEC_TCPCI
+ tristate "Type-C Port Controller Interface driver"
+ help
+ Type-C Port Controller driver for TCPCI-compliant controller.
+
+endif
+
endmenu
diff --git a/drivers/usb/typec/Makefile b/drivers/usb/typec/Makefile
index bbe45721cf52..7dbaf8c3911d 100644
--- a/drivers/usb/typec/Makefile
+++ b/drivers/usb/typec/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_TYPEC)+= typec.o
obj-$(CONFIG_TYPEC_WCOVE) += typec_wcove.o
obj-$(CONFIG_TYPEC_TCPM) += tcpm.o
+obj-$(CONFIG_TYPEC_TCPCI) += tcpci.o
diff --git a/drivers/usb/typec/tcpci.c b/drivers/usb/typec/tcpci.c
new file mode 100644
index ..90cad6cbdceb
--- /dev/null
+++ b/drivers/usb/typec/tcpci.c
@@ -0,0 +1,529 @@
+/*
+ * Copyright 2015-2016 Google, Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * USB Type-C Port Controller Interface.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "tcpci.h"
+#include "tcpm.h"
+
+#define PD_RETRY_COUNT 3
+
+struct tcpci {
+ struct device *dev;
+ struct i2c_client *client;
+
+ struct tcpm_port *port;
+
+ struct regmap *regmap;
+
+ bool controls_vbus;
+
+ struct tcpc_dev tcpc;
+};
+
+static inline struct tcpci *tcpc_to_tcpci(struct tcpc_dev *tcpc)
+{
+ return container_of(tcpc, struct tcpci, tcpc);
+}
+
+static int tcpci_read16(struct tcpci *tcpci, unsigned int reg,
+ unsigned int *val)
+{
+ return regmap_raw_read(tcpci->regmap, reg, val, sizeof(u16));
+}
+
+static int tcpci_write16(struct tcpci *tcpci, unsigned int reg, u16 val)
+{
+ return regmap_raw_write(tcpci->regmap, reg, &val, sizeof(u16));
+}
+
+static int tcpci_set_cc(struct tcpc_dev *tcpc, enum typec_cc_status cc)
+{
+ struct tcpci *tcpci = tcpc_to_tcpci(tcpc);
+ unsigned int reg;
+ int ret;
+
+ switch (cc) {
+ case TYPEC_CC_RA:
+ reg = (TCPC_ROLE_CTRL_CC_RA << TCPC_ROLE_CTRL_CC1_SHIFT) |
+ (TCPC_ROLE_CTRL_CC_RA << TCPC_ROLE_CTRL_CC2_SHIFT);
+ break;
+ case TYPEC_CC_RD:
+ reg = (TCPC_ROLE_CTRL_CC_RD << TCPC_ROLE_CTRL_CC1_SHIFT) |
+ (TCPC_ROLE_CTRL_CC_RD << TCPC_ROLE_CTRL_CC2_SHIFT);
+ break;
+ case TYPEC_CC_RP_DEF:
+ reg = (TCPC_ROLE_CTRL_CC_RP << TCPC_ROLE_CTRL_CC1_SHIFT) |
+ (TCPC_ROLE_CTRL_CC_RP << TCPC_ROLE_CTRL_CC2_SHIFT) |
+ (TCPC_ROLE_CTRL_RP_VAL_DEF <<
+TCPC_ROLE_CTRL_RP_VAL_SHIFT);
+ break;
+ case TYPEC_CC_RP_1_5:
+ reg = (TCPC_ROLE_CTRL_CC_RP << TCPC_ROLE_CTRL_CC1_SHIFT) |
+ (TCPC_ROLE_CTRL_CC_RP << TCPC_ROLE_CTRL_CC2_SHIFT) |
+ (TCPC_ROLE_CTRL_RP_VAL_1_5 <<
+TCPC_ROLE_CTRL_RP_VAL_SHIFT);
+ break;
+ case TYPEC_CC_RP_3_0:
+ reg = (TCPC_ROLE_CTRL_CC_RP << TCPC_ROLE_CTRL_CC1_SHIFT) |
+ (TCPC_ROLE_CTRL_CC_RP << TCPC_ROLE_CTRL_CC2_SHIFT) |
+ (TCPC_ROLE_CTRL_RP_VAL_3_0 <<
+
[RFC v4 0/2] USB Type-C Port Manager
The following series of patches implements a USB Type-C Port Manager using the pending USB Type-C class code as basis. The code is still WIP, but I think it is important to get feedback from the community at this point. There are two patches in the series. The first patch implements the Type-C Port Manager state machine. The second patch is an interface between the Type-C Port Manager and a TCPCI (Type-C Port Controller Interface) compliant USB Type-C Port Controller. Patch 2/2 (the interface to a TCPCI compliant chip) is currently untested since I don't have the necessary hardware available. The port manager code was tested connecting to an Embedded Controller on a Chromebook, bypassing the Port Manager implementation in the EC. Both Source and Sink operation was tested with various Type-C chargers, docks, and connectors. Alternate mode support is partially implemented (Alternate mode support is requested from the partner), but alternate modes are not actually selected. Implementing this will require more thought, since the actual alternate mode support has to be implemented elsewhere, such as in a dedicated Phy driver. It should be possible to implement the interface between phy driver and Type-C Port Controller driver using extcon, but I have not further explored the possibilities, and other options might be possible and/or better. TODO: - Separation of PD, VDM, and TCPM code - Full alternate mode support v4: - tcpm: Source and sink capabilities can now change on the fly - tcpm: Introduced several new macros to identify CC states - tcpm: Determine RP value to set based on maximum current supported by a port configured as source - tcpm: Support for DRP toggling implemented in hardware (by Type-C port controller) - tcpm: Added MODULE_ macros - tcpci: Fix RP value set for ports supporting 3A current - tcpci: Implement support for DRP toggling in hardware - tcpci: When setting VBUS, disable both source and sink before enabling anything - tcpci: Set correct byte count in tcpci_pd_transmit() - tcpci: Disable chip interrupts before registering interrupt handler - tcpci: Request IRQF_ONESHOT | IRQF_TRIGGER_LOW instead of IRQF_TRIGGER_FALLING - Applies on top of v10 of "USB Type-C Connector class" patch series. v3: - Improve TCPM state machine resiliency if there are spurious CC line changes while the state machine is in a transient change (waiting for a timeout) - Update current limit after CC voltage level changes on a port which is not PD capable. - Applies on top of v6 of "USB Type-C Connector class" patch series. v2: - Class code no longer uses locking, so the patch to remove it is no longer necessary. - tcpm: Only update polarity if setting it was successful If setting the CC line polarity in the driver was not successful, don't update the internal polarity state. - tcpm: All PD messages are little endian; convert to and from CPU endianness. - tcpm: Avoid comparisons against NULL. - tcpm: Use u8/u16/u32 instead of uint8_t/uint16_t/uint32_t consistently. - tcpm/tcpc: Callbacks into tcpm need to be lockless to avoid timing problems in low level drivers. - tcpm/tcpc: Simplify callbacks; tcpm can request the current state of cc/vbus when it is ready to use it. - Applies on top of v5 of "USB Type-C Connector class" patch series. -- 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 hot-plug not working (ASUS TP301UA-C4028T)
Hi Mathias,
Just to know: does that mean the firmware from Asus is faulty in here? Do you
think I should contact Asus about this?
Cheers,
Pierre.
Le lundi 3 octobre 2016, 15:09:03 NZDT Mathias Nyman a écrit :
> On 03.10.2016 13:09, Mathias Nyman wrote:
> > I'm writing a workaround that will disable runtime PM for the xhci
> > controller In case we are about to put (keep) it in D0 without PME# wake
> > support.
> >
> > I also learned the lspci -vv might wake up the controller from D3cold so
> > it's also possible that PME# is failing in D3Cold.
> >
> > Could you do two more things to verify the D state so that I fix the right
> > issue:
> >
> > 1. check the D state from sysfs, on-battery, in state where usb devices
> > are not detected: cat
> > /sys/bus/pci/devices/\:00\:14.0/firmware_node/power_state
> >
> > 2. send the DSDT table of your machine, it includes the ACPI methods that
> > dictate the possible D states copy /sys/firmware/acpi/tables/DSDT to a
> > file and send it (a link to it, or attachment) to me, It's binary.
> Thanks, I got the info off-list, and device is really in D0 and ACPI DSDT
> (provided by firmware) is the one enforcing it:
>
> From DSDT:
>
> Scope (_SB.PCI0)
> {
> Device (XHC)
> {
> ...
> Method (_S0W, 0, NotSerialized) // _S0W: S0 Device Wake State
> {
> If (LEqual (XFLT, Zero))
> {
> Return (Zero)
> }
> Else
> {
> Return (Zero)
> }
> }
>
>
> _S0W will return the deepest allowed runtime suspend D state, always zero in
> this case.
>
> Normally if driver has all the needed quirks in place then XFLT == 3 (As
> linux xhci-hcd does) then _S0W usually returns "3". But with this firmware
> _S0W always returns zero. checking XFLT is useless.
>
> Anyways, I'll write a workaround for this case in xhci, disabling runtime PM
> if lowest runtime sleep state (highest D state) is D0 and PME# is disabled
> in D0.
>
> -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: USB will randomly stop working
Coming from the kernel? No there's no kernel lines right before that that have to do with USB. The kernel line before that is: Oct 2 22:21:45 user-desktop kernel: [ 38.122133] Bluetooth: BNEP socket layer initialized. And that's quite a ways up in the file. Also my knowledge of git isn't that extensive and I got the source from the download on the site not from the git repo so it tells me there's no .git file but if I can figure out how to run that I'll give it a go. On Mon, Oct 3, 2016 at 1:21 AM, Greg KH wrote: > On Mon, Oct 03, 2016 at 12:58:48AM -0700, Ashton Holmes wrote: >> This happened back in the 4.8 release candidate and I thought it would >> be fixed when the kernel went stable but I'm still having the issue. >> The kernel seems to randomly reset my USB controller or do something >> to that effect. Basically all my USB devices stop will randomly stop >> working and I have to force reboot the system to get them to come back >> only to have them work for 5 minutes or so before doing it again. I've >> rolled back to 4.7.6 so I can use my system but 4.8 just doesn't seem >> to want to work with USB. I've attached a segment from my syslog that >> I think shows the issue. > >> Oct 2 22:23:31 user-desktop kernel: [ 143.307247] ohci-pci :00:12.0: >> HcDoneHead not written back; disabled >> Oct 2 22:23:31 user-desktop kernel: [ 143.307251] ohci-pci :00:12.0: >> HC died; cleaning up >> Oct 2 22:23:31 user-desktop kernel: [ 143.307292] usb 10-1: USB >> disconnect, device number 2 > > Ick, that's not good, anything right before these lines? > > And you can always let us know that we broke something during the -rc > releases, that way we have a chance to fix it :) > > Along those lines, any chance you can run 'git bisect' to find the > problem patch? > > 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: BUG: scheduling while atomic in f_fs when gadget remove driver
On Mon, Oct 3, 2016 at 1:07 PM, Michal Nazarewicz wrote:
> On Mon, Oct 03 2016, John Stultz wrote:
>> On Wed, Sep 28, 2016 at 2:38 PM, Michal Nazarewicz wrote:
>>> On Wed, Sep 28 2016, Michal Nazarewicz wrote:
With that done, the only thing which needs a mutex is
epfile->read_buffer.
>>>
>>> Perhaps this would do:
>>>
>>> >8 -- -
>>> From 6416a1065203a39328311f6c58083089efe169aa Mon Sep 17 00:00:00 2001
>>> From: Michal Nazarewicz
>>> Date: Wed, 28 Sep 2016 23:36:56 +0200
>>> Subject: [RFC] usb: gadget: f_fs: stop sleeping in ffs_func_eps_disable
>>> MIME-Version: 1.0
>>> Content-Type: text/plain; charset=UTF-8
>>> Content-Transfer-Encoding: 8bit
>>>
>>> ffs_func_eps_disable is called from atomic context so it cannot sleep
>>> thus cannot grab a mutex. Change the handling of epfile->read_buffer
>>> to use non-sleeping synchronisation method.
>>>
>>> Reported-by: Chen Yu
>>> Signed-off-by: Michał Nazarewicz
>>> Fixes: 9353afbbfa7b ("buffer data from ‘oversized’ OUT requests")
>>
>> So the patch here seems to be in some odd encoding?
>
> O_o
> It’s UTF-8.
Yea, I dunno. Simply copied it out of mutt and git am didn't like it.
I think its the "Content-Transfer-Encoding: quoted-printable" main email with
"Content-Transfer-Encoding: 8bit" embedded inside.
Ends up looking like:
Content-Type: text/plain; charset=3DUTF-8
With lots of =3D and =20 values spread about.
>> Can you resend it using git-send-email or in some way other then
>> embedding it inline here? Maybe just point me to a git tree that has
>> it?
>
> https://github.com/mina86/linux.git f-fs-fix
Thanks so much! I'll fetch that and get testing on my side with it as well!
thanks again!
-john
--
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: scheduling while atomic in f_fs when gadget remove driver
On Mon, Oct 03 2016, John Stultz wrote:
> On Wed, Sep 28, 2016 at 2:38 PM, Michal Nazarewicz wrote:
>> On Wed, Sep 28 2016, Michal Nazarewicz wrote:
>>> With that done, the only thing which needs a mutex is
>>> epfile->read_buffer.
>>
>> Perhaps this would do:
>>
>> >8 -- -
>> From 6416a1065203a39328311f6c58083089efe169aa Mon Sep 17 00:00:00 2001
>> From: Michal Nazarewicz
>> Date: Wed, 28 Sep 2016 23:36:56 +0200
>> Subject: [RFC] usb: gadget: f_fs: stop sleeping in ffs_func_eps_disable
>> MIME-Version: 1.0
>> Content-Type: text/plain; charset=UTF-8
>> Content-Transfer-Encoding: 8bit
>>
>> ffs_func_eps_disable is called from atomic context so it cannot sleep
>> thus cannot grab a mutex. Change the handling of epfile->read_buffer
>> to use non-sleeping synchronisation method.
>>
>> Reported-by: Chen Yu
>> Signed-off-by: Michał Nazarewicz
>> Fixes: 9353afbbfa7b ("buffer data from ‘oversized’ OUT requests")
>
> So the patch here seems to be in some odd encoding?
O_o
It’s UTF-8.
> Can you resend it using git-send-email or in some way other then
> embedding it inline here? Maybe just point me to a git tree that has
> it?
https://github.com/mina86/linux.git f-fs-fix
Regardless, I’ll prepare a proper patchset within a few days. Maybe
even now.
--
Best regards
ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] hid: hid-led: fix issue with transfer buffer not being dma capable
The hid-led driver works fine under 4.8.0, however with the next
kernel from today I get this:
[ cut here ]
WARNING: CPU: 0 PID: 2578 at drivers/usb/core/hcd.c:1584
usb_hcd_map_urb_for_dma+0x373/0x550 [usbcore]
transfer buffer not dma capable
Modules linked in: hid_led(+) usbhid vfat fat ir_sony_decoder iwlmvm led_class
mac80211 snd_hda_codec_realtek snd_hda_codec_generic x86_pkg_temp_thermal
iwlwifi crc32c_intel snd_hda_codec_hdmi i2c_i801 i2c_smbus snd_hda_intel
cfg80211 snd_hda_codec snd_hda_core snd_pcm r8169 snd_timer mei_me mii snd mei
ir_lirc_codec lirc_dev nuvoton_cir rc_core btusb btintel bluetooth rfkill
usb_storage efivarfs ipv6 ehci_pci ehci_hcd xhci_pci xhci_hcd usbcore
usb_common ext4 jbd2 mbcache ahci libahci libata
CPU: 0 PID: 2578 Comm: systemd-udevd Not tainted 4.8.0-rc8-next-20161003 #1
Hardware name: ZOTAC ZBOX-CI321NANO/ZBOX-CI321NANO, BIOS B246P105 06/01/2015
c90003dbb7e0 81280425 c90003dbb830
c90003dbb820 8105b086 063003dbb800 88006f374480
0001 880079544000
Call Trace:
[] dump_stack+0x68/0x93
[] __warn+0xc6/0xe0
[] warn_slowpath_fmt+0x4a/0x50
[] usb_hcd_map_urb_for_dma+0x373/0x550 [usbcore]
[] usb_hcd_submit_urb+0x316/0x9c0 [usbcore]
[] ? rcu_read_lock_sched_held+0x40/0x80
[] ? module_assert_mutex_or_preempt+0x13/0x50
[] ? __module_address+0x27/0xf0
[] usb_submit_urb+0x2c4/0x520 [usbcore]
[] usb_start_wait_urb+0x5a/0xe0 [usbcore]
[] usb_control_msg+0xbc/0xf0 [usbcore]
[] ? __module_address+0x27/0xf0
[] usbhid_raw_request+0xa4/0x180 [usbhid]
[] hidled_recv+0x71/0xe0 [hid_led]
[] thingm_init+0x2d/0x50 [hid_led]
[] hidled_probe+0xcb/0x24a [hid_led]
[] hid_device_probe+0xd2/0x150
[] driver_probe_device+0x1fd/0x2c0
[] __driver_attach+0x9a/0xa0
[] ? driver_probe_device+0x2c0/0x2c0
[] bus_for_each_dev+0x5d/0x90
[] driver_attach+0x19/0x20
[] bus_add_driver+0x11f/0x220
[] ? 0xa07ac000
[] driver_register+0x5b/0xd0
[] ? 0xa07ac000
[] __hid_register_driver+0x61/0xa0
[] hidled_driver_init+0x1e/0x20 [hid_led]
[] do_one_initcall+0x38/0x150
[] ? rcu_read_lock_sched_held+0x40/0x80
[] ? kmem_cache_alloc_trace+0x1d0/0x230
[] do_init_module+0x5a/0x1cb
[] load_module+0x1e42/0x2530
[] ? __symbol_put+0x50/0x50
[] ? show_coresize+0x30/0x30
[] ? kernel_read_file+0x100/0x190
[] ? kernel_read_file_from_fd+0x44/0x70
[] SYSC_finit_module+0xba/0xc0
[] SyS_finit_module+0x9/0x10
[] entry_SYSCALL_64_fastpath+0x18/0xad
---[ end trace c9e6ea27003ecf9e ]---
Fix this by using a kmalloc'ed buffer when calling hid_hw_raw_request.
Signed-off-by: Heiner Kallweit
---
v2:
- Based on a comment from Alan Stern allocate the buffer to be provided to
hid_hw_raw_request separately (and not as part of struct hidled_device).
Alternative would have been to allocate the buffer dynamically in each
function calling hidled_send/_recv. However this would mean more overhead
IMHO, and we'd need an error path in callers to free the buffer in case
of an error.
In addition we have better control that a proper buffer is used in case
the driver is extended by somebody for supporting another LED device.
---
drivers/hid/hid-led.c | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/hid/hid-led.c b/drivers/hid/hid-led.c
index d8d55f3..555c88e 100644
--- a/drivers/hid/hid-led.c
+++ b/drivers/hid/hid-led.c
@@ -100,6 +100,7 @@ struct hidled_device {
const struct hidled_config *config;
struct hid_device *hdev;
struct hidled_rgb *rgb;
+ u8 *buf;
struct mutexlock;
};
@@ -118,13 +119,19 @@ static int hidled_send(struct hidled_device *ldev, __u8
*buf)
mutex_lock(&ldev->lock);
+ /*
+* buffer provided to hid_hw_raw_request must not be on the stack
+* and must not be part of a data structure
+*/
+ memcpy(ldev->buf, buf, ldev->config->report_size);
+
if (ldev->config->report_type == RAW_REQUEST)
- ret = hid_hw_raw_request(ldev->hdev, buf[0], buf,
+ ret = hid_hw_raw_request(ldev->hdev, buf[0], ldev->buf,
ldev->config->report_size,
HID_FEATURE_REPORT,
HID_REQ_SET_REPORT);
else if (ldev->config->report_type == OUTPUT_REPORT)
- ret = hid_hw_output_report(ldev->hdev, buf,
+ ret = hid_hw_output_report(ldev->hdev, ldev->buf,
ldev->config->report_size);
else
ret = -EINVAL;
@@ -147,17 +154,21 @@ static int hidled_recv(struct hidled_device *ldev, __u8
*buf)
mutex_lock(&ldev->lock);
- ret = hid_hw_raw_request(ldev->hdev, buf[0],
Re: BUG: scheduling while atomic in f_fs when gadget remove driver
On Wed, Sep 28, 2016 at 2:38 PM, Michal Nazarewicz wrote:
> On Wed, Sep 28 2016, Michal Nazarewicz wrote:
>> With that done, the only thing which needs a mutex is
>> epfile->read_buffer.
>
> Perhaps this would do:
>
> >8 -- -
> From 6416a1065203a39328311f6c58083089efe169aa Mon Sep 17 00:00:00 2001
> From: Michal Nazarewicz
> Date: Wed, 28 Sep 2016 23:36:56 +0200
> Subject: [RFC] usb: gadget: f_fs: stop sleeping in ffs_func_eps_disable
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> ffs_func_eps_disable is called from atomic context so it cannot sleep
> thus cannot grab a mutex. Change the handling of epfile->read_buffer
> to use non-sleeping synchronisation method.
>
> Reported-by: Chen Yu
> Signed-off-by: Michał Nazarewicz
> Fixes: 9353afbbfa7b ("buffer data from ‘oversized’ OUT requests")
So the patch here seems to be in some odd encoding? Can you resend it
using git-send-email or in some way other then embedding it inline
here? Maybe just point me to a git tree that has it?
thanks
-john
--
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] hwrng: chaoskey - drop workaround for old hwrng core limitation
Hello. On 10/03/2016 09:32 PM, Julien Cristau wrote: The hwrng core used to mask 'quality' with 1023; that has been removed in 506bf0c0464ace57169aadcf02ae397999c57bdd, so we can now just set Please follow the commit citing format. Didn't checkpatch.pl complain here? quality to 1024. Signed-off-by: Julien Cristau [...] MBR, Sergei -- 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] hwrng: chaoskey - drop workaround for old hwrng core limitation
The hwrng core used to mask 'quality' with 1023; that has been removed
in 506bf0c0464ace57169aadcf02ae397999c57bdd, so we can now just set
quality to 1024.
Signed-off-by: Julien Cristau
---
drivers/usb/misc/chaoskey.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/usb/misc/chaoskey.c b/drivers/usb/misc/chaoskey.c
index 6ddd08a..aa350dc 100644
--- a/drivers/usb/misc/chaoskey.c
+++ b/drivers/usb/misc/chaoskey.c
@@ -215,19 +215,7 @@ static int chaoskey_probe(struct usb_interface *interface,
dev->hwrng.name = dev->name ? dev->name : chaoskey_driver.name;
dev->hwrng.read = chaoskey_rng_read;
-
- /* Set the 'quality' metric. Quality is measured in units of
-* 1/1024's of a bit ("mills"). This should be set to 1024,
-* but there is a bug in the hwrng core which masks it with
-* 1023.
-*
-* The patch that has been merged to the crypto development
-* tree for that bug limits the value to 1024 at most, so by
-* setting this to 1024 + 1023, we get 1023 before the fix is
-* merged and 1024 afterwards. We'll patch this driver once
-* both bits of code are in the same tree.
-*/
- dev->hwrng.quality = 1024 + 1023;
+ dev->hwrng.quality = 1024;
dev->hwrng_registered = (hwrng_register(&dev->hwrng) == 0);
if (!dev->hwrng_registered)
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] hid: hid-led: fix issue with transfer buffer not being dma capable
Am 03.10.2016 um 20:22 schrieb Alan Stern:
> On Mon, 3 Oct 2016, Heiner Kallweit wrote:
>
>> The hid-led driver works fine under 4.8.0, however with the next
>> kernel from today I get this:
>>
>> [ cut here ]
>> WARNING: CPU: 0 PID: 2578 at drivers/usb/core/hcd.c:1584
>> usb_hcd_map_urb_for_dma+0x373/0x550 [usbcore]
>> transfer buffer not dma capable
>> Modules linked in: hid_led(+) usbhid vfat fat ir_sony_decoder iwlmvm
>> led_class mac80211 snd_hda_codec_realtek snd_hda_codec_generic
>> x86_pkg_temp_thermal iwlwifi crc32c_intel snd_hda_codec_hdmi i2c_i801
>> i2c_smbus snd_hda_intel cfg80211 snd_hda_codec snd_hda_core snd_pcm r8169
>> snd_timer mei_me mii snd mei ir_lirc_codec lirc_dev nuvoton_cir rc_core
>> btusb btintel bluetooth rfkill usb_storage efivarfs ipv6 ehci_pci ehci_hcd
>> xhci_pci xhci_hcd usbcore usb_common ext4 jbd2 mbcache ahci libahci libata
>> CPU: 0 PID: 2578 Comm: systemd-udevd Not tainted 4.8.0-rc8-next-20161003 #1
>> Hardware name: ZOTAC ZBOX-CI321NANO/ZBOX-CI321NANO, BIOS B246P105 06/01/2015
>> c90003dbb7e0 81280425 c90003dbb830
>> c90003dbb820 8105b086 063003dbb800 88006f374480
>> 0001 880079544000
>> Call Trace:
>> [] dump_stack+0x68/0x93
>> [] __warn+0xc6/0xe0
>> [] warn_slowpath_fmt+0x4a/0x50
>> [] usb_hcd_map_urb_for_dma+0x373/0x550 [usbcore]
>> [] usb_hcd_submit_urb+0x316/0x9c0 [usbcore]
>> [] ? rcu_read_lock_sched_held+0x40/0x80
>> [] ? module_assert_mutex_or_preempt+0x13/0x50
>> [] ? __module_address+0x27/0xf0
>> [] usb_submit_urb+0x2c4/0x520 [usbcore]
>> [] usb_start_wait_urb+0x5a/0xe0 [usbcore]
>> [] usb_control_msg+0xbc/0xf0 [usbcore]
>> [] ? __module_address+0x27/0xf0
>> [] usbhid_raw_request+0xa4/0x180 [usbhid]
>> [] hidled_recv+0x71/0xe0 [hid_led]
>> [] thingm_init+0x2d/0x50 [hid_led]
>
> ...
>
>> Fix this by using a kmalloc'ed buffer when calling hid_hw_raw_request.
>>
>> Signed-off-by: Heiner Kallweit
>> ---
>> drivers/hid/hid-led.c | 20 ++--
>> 1 file changed, 14 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/hid/hid-led.c b/drivers/hid/hid-led.c
>> index d8d55f3..6c2b8e0 100644
>> --- a/drivers/hid/hid-led.c
>> +++ b/drivers/hid/hid-led.c
>> @@ -67,6 +67,8 @@ union delcom_packet {
>> #define DELCOM_RED_LED 1
>> #define DELCOM_BLUE_LED 2
>>
>> +#define MAX_REPORT_SIZE 16
>> +
>> struct hidled_device;
>> struct hidled_rgb;
>>
>> @@ -100,11 +102,10 @@ struct hidled_device {
>> const struct hidled_config *config;
>> struct hid_device *hdev;
>> struct hidled_rgb *rgb;
>> +u8 buf[MAX_REPORT_SIZE];
>> struct mutexlock;
>> };
>>
>> -#define MAX_REPORT_SIZE 16
>> -
>> #define to_hidled_led(arg) container_of(arg, struct hidled_led, cdev)
>>
>> static bool riso_kagaku_switch_green_blue;
>> @@ -118,13 +119,16 @@ static int hidled_send(struct hidled_device *ldev,
>> __u8 *buf)
>>
>> mutex_lock(&ldev->lock);
>>
>> +/* buffer provided to hid_hw_raw_request must not be on the stack */
>> +memcpy(ldev->buf, buf, ldev->config->report_size);
>
> In fact, this is not the best way to solve the problem. Not only must
> the buffer be dynamically allocated, it also must not be part of a
> larger structure (such as struct hidled_device).
>
> Instead you should change the routines that call hidled_recv and
> hidled_send. Make each of them allocate a buffer using kmalloc rather
> than use a buffer on the stack.
>
I see, thanks for the hint. I'll provide a v2.
> Alan Stern
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] hid: hid-led: fix issue with transfer buffer not being dma capable
On Mon, 3 Oct 2016, Heiner Kallweit wrote:
> The hid-led driver works fine under 4.8.0, however with the next
> kernel from today I get this:
>
> [ cut here ]
> WARNING: CPU: 0 PID: 2578 at drivers/usb/core/hcd.c:1584
> usb_hcd_map_urb_for_dma+0x373/0x550 [usbcore]
> transfer buffer not dma capable
> Modules linked in: hid_led(+) usbhid vfat fat ir_sony_decoder iwlmvm
> led_class mac80211 snd_hda_codec_realtek snd_hda_codec_generic
> x86_pkg_temp_thermal iwlwifi crc32c_intel snd_hda_codec_hdmi i2c_i801
> i2c_smbus snd_hda_intel cfg80211 snd_hda_codec snd_hda_core snd_pcm r8169
> snd_timer mei_me mii snd mei ir_lirc_codec lirc_dev nuvoton_cir rc_core btusb
> btintel bluetooth rfkill usb_storage efivarfs ipv6 ehci_pci ehci_hcd xhci_pci
> xhci_hcd usbcore usb_common ext4 jbd2 mbcache ahci libahci libata
> CPU: 0 PID: 2578 Comm: systemd-udevd Not tainted 4.8.0-rc8-next-20161003 #1
> Hardware name: ZOTAC ZBOX-CI321NANO/ZBOX-CI321NANO, BIOS B246P105 06/01/2015
> c90003dbb7e0 81280425 c90003dbb830
> c90003dbb820 8105b086 063003dbb800 88006f374480
> 0001 880079544000
> Call Trace:
> [] dump_stack+0x68/0x93
> [] __warn+0xc6/0xe0
> [] warn_slowpath_fmt+0x4a/0x50
> [] usb_hcd_map_urb_for_dma+0x373/0x550 [usbcore]
> [] usb_hcd_submit_urb+0x316/0x9c0 [usbcore]
> [] ? rcu_read_lock_sched_held+0x40/0x80
> [] ? module_assert_mutex_or_preempt+0x13/0x50
> [] ? __module_address+0x27/0xf0
> [] usb_submit_urb+0x2c4/0x520 [usbcore]
> [] usb_start_wait_urb+0x5a/0xe0 [usbcore]
> [] usb_control_msg+0xbc/0xf0 [usbcore]
> [] ? __module_address+0x27/0xf0
> [] usbhid_raw_request+0xa4/0x180 [usbhid]
> [] hidled_recv+0x71/0xe0 [hid_led]
> [] thingm_init+0x2d/0x50 [hid_led]
...
> Fix this by using a kmalloc'ed buffer when calling hid_hw_raw_request.
>
> Signed-off-by: Heiner Kallweit
> ---
> drivers/hid/hid-led.c | 20 ++--
> 1 file changed, 14 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/hid/hid-led.c b/drivers/hid/hid-led.c
> index d8d55f3..6c2b8e0 100644
> --- a/drivers/hid/hid-led.c
> +++ b/drivers/hid/hid-led.c
> @@ -67,6 +67,8 @@ union delcom_packet {
> #define DELCOM_RED_LED 1
> #define DELCOM_BLUE_LED 2
>
> +#define MAX_REPORT_SIZE 16
> +
> struct hidled_device;
> struct hidled_rgb;
>
> @@ -100,11 +102,10 @@ struct hidled_device {
> const struct hidled_config *config;
> struct hid_device *hdev;
> struct hidled_rgb *rgb;
> + u8 buf[MAX_REPORT_SIZE];
> struct mutexlock;
> };
>
> -#define MAX_REPORT_SIZE 16
> -
> #define to_hidled_led(arg) container_of(arg, struct hidled_led, cdev)
>
> static bool riso_kagaku_switch_green_blue;
> @@ -118,13 +119,16 @@ static int hidled_send(struct hidled_device *ldev, __u8
> *buf)
>
> mutex_lock(&ldev->lock);
>
> + /* buffer provided to hid_hw_raw_request must not be on the stack */
> + memcpy(ldev->buf, buf, ldev->config->report_size);
In fact, this is not the best way to solve the problem. Not only must
the buffer be dynamically allocated, it also must not be part of a
larger structure (such as struct hidled_device).
Instead you should change the routines that call hidled_recv and
hidled_send. Make each of them allocate a buffer using kmalloc rather
than use a buffer on the stack.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] hid: hid-led: fix issue with transfer buffer not being dma capable
The hid-led driver works fine under 4.8.0, however with the next
kernel from today I get this:
[ cut here ]
WARNING: CPU: 0 PID: 2578 at drivers/usb/core/hcd.c:1584
usb_hcd_map_urb_for_dma+0x373/0x550 [usbcore]
transfer buffer not dma capable
Modules linked in: hid_led(+) usbhid vfat fat ir_sony_decoder iwlmvm led_class
mac80211 snd_hda_codec_realtek snd_hda_codec_generic x86_pkg_temp_thermal
iwlwifi crc32c_intel snd_hda_codec_hdmi i2c_i801 i2c_smbus snd_hda_intel
cfg80211 snd_hda_codec snd_hda_core snd_pcm r8169 snd_timer mei_me mii snd mei
ir_lirc_codec lirc_dev nuvoton_cir rc_core btusb btintel bluetooth rfkill
usb_storage efivarfs ipv6 ehci_pci ehci_hcd xhci_pci xhci_hcd usbcore
usb_common ext4 jbd2 mbcache ahci libahci libata
CPU: 0 PID: 2578 Comm: systemd-udevd Not tainted 4.8.0-rc8-next-20161003 #1
Hardware name: ZOTAC ZBOX-CI321NANO/ZBOX-CI321NANO, BIOS B246P105 06/01/2015
c90003dbb7e0 81280425 c90003dbb830
c90003dbb820 8105b086 063003dbb800 88006f374480
0001 880079544000
Call Trace:
[] dump_stack+0x68/0x93
[] __warn+0xc6/0xe0
[] warn_slowpath_fmt+0x4a/0x50
[] usb_hcd_map_urb_for_dma+0x373/0x550 [usbcore]
[] usb_hcd_submit_urb+0x316/0x9c0 [usbcore]
[] ? rcu_read_lock_sched_held+0x40/0x80
[] ? module_assert_mutex_or_preempt+0x13/0x50
[] ? __module_address+0x27/0xf0
[] usb_submit_urb+0x2c4/0x520 [usbcore]
[] usb_start_wait_urb+0x5a/0xe0 [usbcore]
[] usb_control_msg+0xbc/0xf0 [usbcore]
[] ? __module_address+0x27/0xf0
[] usbhid_raw_request+0xa4/0x180 [usbhid]
[] hidled_recv+0x71/0xe0 [hid_led]
[] thingm_init+0x2d/0x50 [hid_led]
[] hidled_probe+0xcb/0x24a [hid_led]
[] hid_device_probe+0xd2/0x150
[] driver_probe_device+0x1fd/0x2c0
[] __driver_attach+0x9a/0xa0
[] ? driver_probe_device+0x2c0/0x2c0
[] bus_for_each_dev+0x5d/0x90
[] driver_attach+0x19/0x20
[] bus_add_driver+0x11f/0x220
[] ? 0xa07ac000
[] driver_register+0x5b/0xd0
[] ? 0xa07ac000
[] __hid_register_driver+0x61/0xa0
[] hidled_driver_init+0x1e/0x20 [hid_led]
[] do_one_initcall+0x38/0x150
[] ? rcu_read_lock_sched_held+0x40/0x80
[] ? kmem_cache_alloc_trace+0x1d0/0x230
[] do_init_module+0x5a/0x1cb
[] load_module+0x1e42/0x2530
[] ? __symbol_put+0x50/0x50
[] ? show_coresize+0x30/0x30
[] ? kernel_read_file+0x100/0x190
[] ? kernel_read_file_from_fd+0x44/0x70
[] SYSC_finit_module+0xba/0xc0
[] SyS_finit_module+0x9/0x10
[] entry_SYSCALL_64_fastpath+0x18/0xad
---[ end trace c9e6ea27003ecf9e ]---
Fix this by using a kmalloc'ed buffer when calling hid_hw_raw_request.
Signed-off-by: Heiner Kallweit
---
drivers/hid/hid-led.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/hid/hid-led.c b/drivers/hid/hid-led.c
index d8d55f3..6c2b8e0 100644
--- a/drivers/hid/hid-led.c
+++ b/drivers/hid/hid-led.c
@@ -67,6 +67,8 @@ union delcom_packet {
#define DELCOM_RED_LED 1
#define DELCOM_BLUE_LED2
+#define MAX_REPORT_SIZE16
+
struct hidled_device;
struct hidled_rgb;
@@ -100,11 +102,10 @@ struct hidled_device {
const struct hidled_config *config;
struct hid_device *hdev;
struct hidled_rgb *rgb;
+ u8 buf[MAX_REPORT_SIZE];
struct mutexlock;
};
-#define MAX_REPORT_SIZE16
-
#define to_hidled_led(arg) container_of(arg, struct hidled_led, cdev)
static bool riso_kagaku_switch_green_blue;
@@ -118,13 +119,16 @@ static int hidled_send(struct hidled_device *ldev, __u8
*buf)
mutex_lock(&ldev->lock);
+ /* buffer provided to hid_hw_raw_request must not be on the stack */
+ memcpy(ldev->buf, buf, ldev->config->report_size);
+
if (ldev->config->report_type == RAW_REQUEST)
- ret = hid_hw_raw_request(ldev->hdev, buf[0], buf,
+ ret = hid_hw_raw_request(ldev->hdev, buf[0], ldev->buf,
ldev->config->report_size,
HID_FEATURE_REPORT,
HID_REQ_SET_REPORT);
else if (ldev->config->report_type == OUTPUT_REPORT)
- ret = hid_hw_output_report(ldev->hdev, buf,
+ ret = hid_hw_output_report(ldev->hdev, ldev->buf,
ldev->config->report_size);
else
ret = -EINVAL;
@@ -147,17 +151,21 @@ static int hidled_recv(struct hidled_device *ldev, __u8
*buf)
mutex_lock(&ldev->lock);
- ret = hid_hw_raw_request(ldev->hdev, buf[0], buf,
+ memcpy(ldev->buf, buf, ldev->config->report_size);
+
+ ret = hid_hw_raw_request(ldev->hdev, buf[0], ldev->buf,
ldev->config->report_size,
Re: [RFC/PATCH 27/45] usb: musb: make use of new usb_endpoint_maxp_mult()
On Wed, Sep 28, 2016 at 04:05:36PM +0300, Felipe Balbi wrote:
> We have introduced a helper to calculate multiplier
> value from wMaxPacketSize. Start using it.
>
> Cc: Bin Liu
> Signed-off-by: Felipe Balbi
> ---
> drivers/usb/musb/musb_gadget.c | 6 +++---
> drivers/usb/musb/musb_host.c | 2 +-
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
> index bff4869a57cd..8a0882cc446d 100644
> --- a/drivers/usb/musb/musb_gadget.c
> +++ b/drivers/usb/musb/musb_gadget.c
> @@ -974,8 +974,8 @@ static int musb_gadget_enable(struct usb_ep *ep,
> goto fail;
>
> /* REVISIT this rules out high bandwidth periodic transfers */
> - tmp = usb_endpoint_maxp(desc);
The bit 10~0 in tmp is also needed in the original code,
> - if (tmp & ~0x07ff) {
> + tmp = usb_endpoint_maxp_mult(desc) - 1;
but here bit 10~0 is lost.
Regards,
-Bin.
> + if (tmp) {
> int ok;
>
> if (usb_endpoint_dir_in(desc))
> @@ -987,7 +987,7 @@ static int musb_gadget_enable(struct usb_ep *ep,
> musb_dbg(musb, "no support for high bandwidth ISO");
> goto fail;
> }
> - musb_ep->hb_mult = (tmp >> 11) & 3;
> + musb_ep->hb_mult = tmp;
> } else {
> musb_ep->hb_mult = 0;
> }
> diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
> index 53bc4ceefe89..f6cdbad00dac 100644
> --- a/drivers/usb/musb/musb_host.c
> +++ b/drivers/usb/musb/musb_host.c
> @@ -2237,7 +2237,7 @@ static int musb_urb_enqueue(
>* Some musb cores don't support high bandwidth ISO transfers; and
>* we don't (yet!) support high bandwidth interrupt transfers.
>*/
> - qh->hb_mult = 1 + ((qh->maxpacket >> 11) & 0x03);
> + qh->hb_mult = usb_endpoint_maxp_mult(epd);
> if (qh->hb_mult > 1) {
> int ok = (qh->type == USB_ENDPOINT_XFER_ISOC);
>
> --
> 2.10.0.440.g21f862b
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 01/45] usb: add helper to extract bits 12:11 of wMaxPacketSize
On Wed, Sep 28, 2016 at 04:05:10PM +0300, Felipe Balbi wrote:
> According to USB Specification 2.0 table 9-4,
> wMaxPacketSize is a bitfield. Endpoint's maxpacket
> is laid out in bits 10:0. For high-speed,
> high-bandwidth isochronous endpoints, bits 12:11
> contain a multiplier to tell us how many
> transactions we want to try per uframe.
>
> This means that if we want an isochronous endpoint
> to issue 3 transfers of 1024 bytes per uframe,
> wMaxPacketSize should contain the value:
>
> 1024 | (2 << 11)
>
> or 5120 (0x1400). In order to make Host and
> Peripheral controller drivers' life easier, we're
> adding a helper which returns bits 12:11. Note that
> no care is made WRT to checking endpoint type and
> gadget's speed. That's left for drivers to handle.
>
> Signed-off-by: Felipe Balbi
> ---
> include/uapi/linux/usb/ch9.h | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/include/uapi/linux/usb/ch9.h b/include/uapi/linux/usb/ch9.h
> index a8acc24765fe..7628dff5fac3 100644
> --- a/include/uapi/linux/usb/ch9.h
> +++ b/include/uapi/linux/usb/ch9.h
> @@ -423,6 +423,11 @@ struct usb_endpoint_descriptor {
> #define USB_ENDPOINT_XFER_INT3
> #define USB_ENDPOINT_MAX_ADJUSTABLE 0x80
>
> +#define USB_EP_MAXP_MULT_SHIFT 11
> +#define USB_EP_MAXP_MULT_MASK(3 << USB_EP_MAXP_MULT_SHIFT)
> +#define USB_EP_MAXP_MULT(m) \
> + (((m) & USB_EP_MAXP_MULT_MASK) >> USB_EP_MAXP_MULT_SHIFT)
> +
> /* The USB 3.0 spec redefines bits 5:4 of bmAttributes as interrupt ep type.
> */
> #define USB_ENDPOINT_INTRTYPE0x30
> #define USB_ENDPOINT_INTR_PERIODIC (0 << 4)
> @@ -630,6 +635,20 @@ static inline int usb_endpoint_maxp(const struct
> usb_endpoint_descriptor *epd)
> return __le16_to_cpu(epd->wMaxPacketSize);
> }
>
> +/**
> + * usb_endpoint_maxp_mult - get endpoint's transactional opportunities
> + * @epd: endpoint to be checked
> + *
> + * Return @epd's wMaxPacketSize[12:11] + 1
> + */
> +static inline int
> +usb_endpoint_maxp_mult(const struct usb_endpoint_descriptor *epd)
> +{
> + int maxp = __le16_to_cpu(epd->wMaxPacketSize);
> +
> + return USB_EP_MAXP_MULT(maxp) + 1;
It seems the instances which use 1 based value is less than those use 0
based. To me it seems make sense to just return 0 based value here.
Some controllers like musb writes the 0 based value to a register.
Regards,
-Bin.
> +}
> +
> static inline int usb_endpoint_interrupt_type(
> const struct usb_endpoint_descriptor *epd)
> {
> --
> 2.10.0.440.g21f862b
>
> --
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 15/45] usb: chipidea: udc: make use of new usb_endpoint_maxp_mult()
On Wed, Sep 28, 2016 at 04:05:24PM +0300, Felipe Balbi wrote: > We have introduced a helper to calculate multiplier > value from wMaxPacketSize. Start using it. > > Cc: Peter Chen > Cc: > Signed-off-by: Felipe Balbi > --- > drivers/usb/chipidea/udc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c > index 661f43fe0f9e..2b95ca887ca4 100644 > --- a/drivers/usb/chipidea/udc.c > +++ b/drivers/usb/chipidea/udc.c > @@ -1254,7 +1254,7 @@ static int ep_enable(struct usb_ep *ep, > hwep->type = usb_endpoint_type(desc); > > hwep->ep.maxpacket = usb_endpoint_maxp(desc) & 0x07ff; > - hwep->ep.mult = QH_ISO_MULT(usb_endpoint_maxp(desc)); The original code is 0 based, > + hwep->ep.mult = usb_endpoint_maxp_mult(desc); now the new code makes it 1 based. Regards, -Bin. > > if (hwep->type == USB_ENDPOINT_XFER_CONTROL) > cap |= QH_IOS; > -- > 2.10.0.440.g21f862b > > -- > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 16/45] usb: core: devices: make use of new usb_endpoint_maxp_mult()
On Wed, Sep 28, 2016 at 04:05:25PM +0300, Felipe Balbi wrote:
> We have introduced a helper to calculate multiplier
> value from wMaxPacketSize. Start using it.
>
> Cc: Greg Kroah-Hartman
> Cc:
> Signed-off-by: Felipe Balbi
> ---
> drivers/usb/core/devices.c | 10 ++
> 1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/usb/core/devices.c b/drivers/usb/core/devices.c
> index ef04b50e6bbb..00d1b26a81d3 100644
> --- a/drivers/usb/core/devices.c
> +++ b/drivers/usb/core/devices.c
> @@ -182,14 +182,8 @@ static char *usb_dump_endpoint_descriptor(int speed,
> char *start, char *end,
>
> dir = usb_endpoint_dir_in(desc) ? 'I' : 'O';
>
> - if (speed == USB_SPEED_HIGH) {
> - switch (usb_endpoint_maxp(desc) & (0x03 << 11)) {
This is 0 based,
> - case 1 << 11:
> - bandwidth = 2; break;
> - case 2 << 11:
> - bandwidth = 3; break;
> - }
> - }
> + if (speed == USB_SPEED_HIGH)
> + bandwidth = usb_endpoint_maxp_mult(desc);
Now the new code makes it 1 based.
Regards,
-Bin.
>
> /* this isn't checking for illegal values */
> switch (usb_endpoint_type(desc)) {
> --
> 2.10.0.440.g21f862b
>
> --
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 40/45] usb: gadget: udc: s3c2410: remove unnecessary & operation
On Wed, Sep 28, 2016 at 04:05:49PM +0300, Felipe Balbi wrote: > Now that usb_endpoint_maxp() only returns the lowest > 11 bits from wMaxPacketSize, we can remove the & > operation from this driver. > > Signed-off-by: Felipe Balbi > --- > drivers/usb/gadget/udc/s3c2410_udc.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/usb/gadget/udc/s3c2410_udc.c > b/drivers/usb/gadget/udc/s3c2410_udc.c > index eb3571ee59e3..4643a01262b4 100644 > --- a/drivers/usb/gadget/udc/s3c2410_udc.c > +++ b/drivers/usb/gadget/udc/s3c2410_udc.c > @@ -1047,10 +1047,10 @@ static int s3c2410_udc_ep_enable(struct usb_ep *_ep, > if (!dev->driver || dev->gadget.speed == USB_SPEED_UNKNOWN) > return -ESHUTDOWN; > > - max = usb_endpoint_maxp(desc) & 0x1fff; > + max = usb_endpoint_maxp(desc); This loses bit 11 & 12. Regards, -Bin. > > local_irq_save(flags); > - _ep->maxpacket = max & 0x7ff; > + _ep->maxpacket = max; > ep->ep.desc = desc; > ep->halted = 0; > ep->bEndpointAddress = desc->bEndpointAddress; > -- > 2.10.0.440.g21f862b > > -- > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 39/45] usb: gadget: udc: net2280: remove unnecessary & operation
On Wed, Sep 28, 2016 at 04:05:48PM +0300, Felipe Balbi wrote:
> Now that usb_endpoint_maxp() only returns the lowest
> 11 bits from wMaxPacketSize, we can remove the &
> operation from this driver.
>
> Signed-off-by: Felipe Balbi
> ---
> drivers/usb/gadget/udc/net2280.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/gadget/udc/net2280.c
> b/drivers/usb/gadget/udc/net2280.c
> index 61c938c36d88..85504419ab31 100644
> --- a/drivers/usb/gadget/udc/net2280.c
> +++ b/drivers/usb/gadget/udc/net2280.c
> @@ -224,14 +224,14 @@ net2280_enable(struct usb_ep *_ep, const struct
> usb_endpoint_descriptor *desc)
> }
>
> /* sanity check ep-e/ep-f since their fifos are small */
> - max = usb_endpoint_maxp(desc) & 0x1fff;
> + max = usb_endpoint_maxp(desc);
The mask is 0x1fff, which keeps bit 11 & 12.
> if (ep->num > 4 && max > 64 && (dev->quirks & PLX_LEGACY)) {
> ret = -ERANGE;
> goto print_err;
> }
>
> spin_lock_irqsave(&dev->lock, flags);
> - _ep->maxpacket = max & 0x7ff;
> + _ep->maxpacket = max;
> ep->desc = desc;
>
> /* ep_reset() has already been called */
> @@ -1839,7 +1839,7 @@ static ssize_t queues_show(struct device *_dev, struct
> device_attribute *attr,
> ep->ep.name, t & USB_ENDPOINT_NUMBER_MASK,
> (t & USB_DIR_IN) ? "in" : "out",
> type_string(d->bmAttributes),
> - usb_endpoint_maxp(d) & 0x1fff,
> + usb_endpoint_maxp(d),
The same here.
Regards,
-Bin.
> ep->dma ? "dma" : "pio", ep->fifo_size
> );
> } else /* ep0 should only have one transfer queued */
> --
> 2.10.0.440.g21f862b
>
> --
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 38/45] usb: gadget: udc: net2272: remove unnecessary & operation
On Wed, Sep 28, 2016 at 04:05:47PM +0300, Felipe Balbi wrote: > Now that usb_endpoint_maxp() only returns the lowest > 11 bits from wMaxPacketSize, we can remove the & > operation from this driver. > > Signed-off-by: Felipe Balbi > --- > drivers/usb/gadget/udc/net2272.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/usb/gadget/udc/net2272.c > b/drivers/usb/gadget/udc/net2272.c > index 7c6113432093..078c91d546e0 100644 > --- a/drivers/usb/gadget/udc/net2272.c > +++ b/drivers/usb/gadget/udc/net2272.c > @@ -202,10 +202,10 @@ net2272_enable(struct usb_ep *_ep, const struct > usb_endpoint_descriptor *desc) > if (!dev->driver || dev->gadget.speed == USB_SPEED_UNKNOWN) > return -ESHUTDOWN; > > - max = usb_endpoint_maxp(desc) & 0x1fff; > + max = usb_endpoint_maxp(desc); The mask is 0x1fff, which keeps bit 11 & 12. > > spin_lock_irqsave(&dev->lock, flags); > - _ep->maxpacket = max & 0x7fff; > + _ep->maxpacket = max; Here it masks out bit 11 & 12. Regards, -Bin. > ep->desc = desc; > > /* net2272_ep_reset() has already been called */ > -- > 2.10.0.440.g21f862b > > -- > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 22/45] usb: gadget: udc: gr: make use of new usb_endpoint_maxp_mult()
On Wed, Sep 28, 2016 at 04:05:31PM +0300, Felipe Balbi wrote:
> We have introduced a helper to calculate multiplier
> value from wMaxPacketSize. Start using it.
>
> Signed-off-by: Felipe Balbi
> ---
> drivers/usb/gadget/udc/gr_udc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/gadget/udc/gr_udc.c b/drivers/usb/gadget/udc/gr_udc.c
> index 39b7136d31d9..3786b5dbfd01 100644
> --- a/drivers/usb/gadget/udc/gr_udc.c
> +++ b/drivers/usb/gadget/udc/gr_udc.c
> @@ -1539,7 +1539,7 @@ static int gr_ep_enable(struct usb_ep *_ep,
>* additional transactions.
>*/
> max = 0x7ff & usb_endpoint_maxp(desc);
> - nt = 0x3 & (usb_endpoint_maxp(desc) >> 11);
> + nt = usb_endpoint_maxp_mult(desc);
In the original code, nt is 0 based, now the new code makes it 1 based.
Regards,
-Bin.
> buffer_size = GR_BUFFER_SIZE(epctrl);
> if (nt && (mode == 0 || mode == 2)) {
> dev_err(dev->dev,
> --
> 2.10.0.440.g21f862b
>
> --
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 21/45] usb: gadget: udc: fusb300: make use of new usb_endpoint_maxp_mult()
On Wed, Sep 28, 2016 at 04:05:30PM +0300, Felipe Balbi wrote:
> We have introduced a helper to calculate multiplier
> value from wMaxPacketSize. Start using it.
>
> Signed-off-by: Felipe Balbi
> ---
> drivers/usb/gadget/udc/fusb300_udc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/gadget/udc/fusb300_udc.c
> b/drivers/usb/gadget/udc/fusb300_udc.c
> index 948845c90e47..42ff308578df 100644
> --- a/drivers/usb/gadget/udc/fusb300_udc.c
> +++ b/drivers/usb/gadget/udc/fusb300_udc.c
> @@ -218,7 +218,7 @@ static int config_ep(struct fusb300_ep *ep,
> (info.type == USB_ENDPOINT_XFER_ISOC)) {
> info.interval = desc->bInterval;
> if (info.type == USB_ENDPOINT_XFER_ISOC)
> - info.bw_num = ((desc->wMaxPacketSize & 0x1800) >> 11);
> + info.bw_num = usb_endpoint_maxp_mult(desc);
In the original code, bw_num is 0 based, now the new code makes it 1
based.
Regards,
-Bin.
> }
>
> ep_fifo_setting(fusb300, info);
> --
> 2.10.0.440.g21f862b
>
> --
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 19/45] usb: gadget: udc: dummy: make use of new usb_endpoint_maxp_mult()
On Wed, Sep 28, 2016 at 04:05:28PM +0300, Felipe Balbi wrote: > We have introduced a helper to calculate multiplier > value from wMaxPacketSize. Start using it. > > Cc: Alan Stern > Cc: > Signed-off-by: Felipe Balbi > --- > drivers/usb/gadget/udc/dummy_hcd.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/usb/gadget/udc/dummy_hcd.c > b/drivers/usb/gadget/udc/dummy_hcd.c > index 77d07904f932..14004cf88d4d 100644 > --- a/drivers/usb/gadget/udc/dummy_hcd.c > +++ b/drivers/usb/gadget/udc/dummy_hcd.c > @@ -1483,8 +1483,7 @@ static int periodic_bytes(struct dummy *dum, struct > dummy_ep *ep) > int tmp; > > /* high bandwidth mode */ > - tmp = usb_endpoint_maxp(ep->desc); > - tmp = (tmp >> 11) & 0x03; > + tmp = usb_endpoint_maxp_mult(ep->desc); In the original code, tmp is 0 based, now the new code makes it 1 based. Regards, -Bin. > tmp *= 8 /* applies to entire frame */; > limit += limit * tmp; > } > -- > 2.10.0.440.g21f862b > > -- > 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 -- 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 V10 1/1] usb:serial: Add Fintek F81532/534 driver
On Thu, Sep 01, 2016 at 09:56:01AM +0800, Ji-Ze Hong (Peter Hong) wrote: > This driver is for Fintek F81532/F81534 USB to Serial Ports IC. > > F81532 spec: > https://drive.google.com/file/d/0B8vRwwYO7aMFOTRRMmhWQVNvajQ/view?usp= > sharing > > F81534 spec: > https://drive.google.com/file/d/0B8vRwwYO7aMFV29pQWJqbVBNc00/view?usp= > sharing > > Features: > 1. F81532 is 1-to-2 & F81534 is 1-to-4 serial ports IC > 2. Support Baudrate from B50 to B115200. > > Signed-off-by: Ji-Ze Hong (Peter Hong) > --- > Changelog: > V10 > 1. Change the submit/kill timming for read URBs, submit when first >serial port open and kill when final port close. > 2. Remove all source code about controlling GPIOs. > 3. Change the f81534_tiocmget() from reading shadow MSR with delay >20ms to read MSR register directly. > 4. Using tty_port_initialized() to check port opened/closed. > 5. Add sanity check for variables. > > v9 > 1. Remove lots of code to make more generic for F81532/534. e.g., >high baud rate support, RS485/422 mode switch, most of GPIO >control and internal storage write functional. > 2. Change f81534_tiocmget() MSR delay from schedule_timeout_killable() >to wait_for_completion_killable_timeout(). This IC will delayed >receiving MSR change when doing loop-back test e.g., BurnInTest. >We'll reset completion "msr_done" in f81534_update_mctrl(). If we >changed MCR, the next f81534_tiocmget() will delay for 20ms or >continue with new MSR arrived. > 3. Fix for non-zero buffer allocated in f81534_setup_ports(). It'll >make device malfunctional with incorrect tx length for other ports. > > v8 > 1. Remove driver mode GPIOLIB & RS485 control support, the driver will >only load GPIO/UART Mode when driver attach() & port_probe(). > 2. Add more documents for 3 generation IC with f81534_calc_num_ports(). > 3. Simplify the GPIO register structure "f81534_pin_control". > 4. Change all counter type from int to size_t. > 5. Change some failed message with failed: "status code" and remove all >exclamation mark in messages. > 6. Change all save blocks to block0 due to the driver is only used 1 >block (block0) to save data. > 7. Change read MSR in open() instead of port_probe(). > 8. use GFP_ATOMIC kmalloc mode in write(). > 9. Maintain old style with 1 read URBs and 4 write URBs like mxuports.c >I had tested with submit 4 read URBs, but it'll make some port freeze >when doing BurnInTest Port test. > > v7 > 1. Make all gpiolib function with #ifdef CONFIG_GPIOLIB marco block. >Due to F81532/534 could run without gpiolib, we implements >f81534_prepare_gpio()/f81534_release_gpio() always success without >CONFIG_GPIOLIB. > 2. Fix crash when receiving MSR change on driver load/unload. It's cause >by f81534_process_read_urb() get read URB callback data, but port >private data is not init complete or released. We solve with 2 >modifications. > >1. add null pointer check with f81534_process_read_urb(). We'll skip > this report when port_priv = NULL. >2. when "one" port f81534_port_remove() is called, kill the port-0 > read URB before kfree port_priv. > > v6 > 1. Re-implement the write()/resume() function. Due to this device cant be >suitable with generic write(), we'll do the submit write URB when >write()/received tx empty/set_termios()/resume() > 2. Logic/Phy Port mapping rewrite in f81534_port_probe() & >f81534_phy_to_logic_port(). > 3. Introduced "Port Hide" function. Some customer use F81532 reference >design for HW layout, but really use F81534 IC. We'll check >F81534_PORT_CONF_DISABLE_PORT flag with in uart mode field to do >port hide with port not used. It can be avoid end-user to use not >layouted port. > 4. The 4x3 output-only open-drain pins for F81532/534 is designed for >control outer devices (with our EVB for examples, the 4 sets of pins >are designed to control transceiver mode). So we decide to implement >with gpiolib interface. > 5. Add device vendor id with 0x2c42 > > v5 > 1. Change f81534_port_disable/enable() from H/W mode to S/W mode >It'll skip all rx data when port is not opened. > 2. Some function modifier add with static (Thanks for Paul Bolle) > 3. It's will direct return when count=0 in f81534_write() to >reduce spin_lock usage. > > v4 > 1. clearify f81534_process_read_urb() with >f81534_process_per_serial_block(). (referenced from mxuport.c) > 2. We limited f81534_write() max tx kfifo with 124Bytes. >Original subsystem is designed for auto tranmiting fifo data >if available. But we must wait for tx_empty for next tx data >(H/W design). > >With this kfifo size lim
Re: [RFC/PATCH 18/45] usb: gadget: udc: bdc: make use of new usb_endpoint_maxp_mult()
On Wed, Sep 28, 2016 at 04:05:27PM +0300, Felipe Balbi wrote:
> We have introduced a helper to calculate multiplier
> value from wMaxPacketSize. Start using it.
>
> Cc: Ashwini Pahuja
> Cc:
> Signed-off-by: Felipe Balbi
> ---
> drivers/usb/gadget/udc/bdc/bdc_cmd.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/gadget/udc/bdc/bdc_cmd.c
> b/drivers/usb/gadget/udc/bdc/bdc_cmd.c
> index 4d5e9188beae..6e920f1dce02 100644
> --- a/drivers/usb/gadget/udc/bdc/bdc_cmd.c
> +++ b/drivers/usb/gadget/udc/bdc/bdc_cmd.c
> @@ -182,7 +182,7 @@ int bdc_config_ep(struct bdc *bdc, struct bdc_ep *ep)
> usb_endpoint_xfer_int(desc)) {
> param2 |= si;
>
> - mbs = (usb_endpoint_maxp(desc) & 0x1800) >> 11;
> + mbs = usb_endpoint_maxp_mult(desc);
In the original code mbs is 0 based. Now the new code makes it 1 based.
Regards,
-Bin.
> param2 |= mbs << MB_SHIFT;
> }
> break;
> --
> 2.10.0.440.g21f862b
>
> --
> 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
--
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] Revert "usb: dwc3: gadget: use allocated/queued reqs for LST bit"
Hi,
ville.syrj...@linux.intel.com writes:
> From: Ville Syrjälä
>
> This reverts commit 55a0237f8f47957163125e20ee9260538c5c341c.
>
> commit 55a0237f8f47 ("usb: dwc3: gadget: use allocated/queued reqs for
> LST bit") causes my BYT FFRD8 with g_ether to behave poorly. ssh/scp
> is very sluggish and can even stall entirely. Revert cures it.
>
> Cc: Felipe Balbi
> Cc: sta...@vger.kernel.org
> Signed-off-by: Ville Syrjälä
Reverting that commit is not the best idea. Let's start with the usual:
- Kernel version
- dmesg on both sides (host and device)
- dwc3 tracepoints:
# mkdir -p /t
# mount -t tracefs none /t
# echo 8192 > /t/buffer_size_kb
# echo 1 > /t/events/dwc3/enable
# echo 0 > /t/events/dwc3/dwc3_readl/enable
# echo 0 > /t/events/dwc3/dwc3_writel/enable
This should be enough to tell me what's really going on.
--
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
[GIT PULL] USB driver patches for 4.9-rc1
The following changes since commit 3be7988674ab33565700a37b210f502563d932e6: Linux 4.8-rc7 (2016-09-18 17:27:41 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-4.9-rc1 for you to fetch changes up to ab21b63e8aedfc73565dd9cdd51eb338341177cb: Revert "usbtmc: convert to devm_kzalloc" (2016-09-28 11:51:30 +0200) USB/PHY/EXTCON patches for 4.9-rc1 Here is the big USB, and PHY, and extcon, patchsets for 4.9-rc1. Full details are in the shortlog, but generally a lot of new hardware support, usb gadget updates, and Wolfram's great cleanup of USB error message handling, making the kernel image a tad bit smaller. All of this has been in linux-next with no reported issues. Signed-off-by: Greg Kroah-Hartman Alan Stern (1): usb-storage: MAINTAINERS: Alan Stern is the new maintainer Alexey Khoroshilov (1): usb: gadget: goku_udc: fix memory leak in goku_probe() Andreas Kemnade (2): phy-twl4030-usb: better handle musb_mailbox() failure phy-twl4030-usb: initialize charging-related stuff via pm_runtime Anurag Kumar Vulisha (1): usb: dwc3: of-simple: Fix warning during unbind Arnd Bergmann (4): usb: dwc3: avoid -Wmaybe-uninitialized warning usb: phy: add USB_SUPPORT dependency usb: gadget: uvc: add V4L2 dependency usb: musb: da8xx: fix error handling message in probe Axel Lin (3): phy: exynos5-usbdrd: Remove "static" from local variable phy: bcm-ns2-pcie: Get rid of struct ns2_pci_phy phy: bcm-ns2-pcie: Set missing .owner field in ns2_pci_phy_ops Baolin Wang (1): usb: dwc3: core: Move the mode setting to the right place Baoyou Xie (3): phy: tegra: add missing header dependencies phy: tegra: mark tegra_xusb_lane_lookup_function() static usb: core: hcd: add missing header dependencies Bhaktipriya Shridhar (6): usb: lvstest: Remove deprecated create_singlethread_workqueue USB: appledisplay: Remove deprecated create_singlethread_workqueue usb: ftdi-elan: Remove deprecated create_singlethread_workqueue usb: dwc2: Remove deprecated create_singlethread_workqueue whci: Remove deprecated create_singlethread_workqueue usb: dwc2: Remove deprecated create_singlethread_workqueue Bjørn Mork (1): cdc-wdm: fix "out-of-sync" due to missing notifications Brian Norris (1): Documentation: dt: dwc3: note the supported phy-names Chanwoo Choi (25): extcon: arizona: Remove the usage of extcon_update_state() extcon: adc-jack: Remove the usage of extcon_set_state() extcon: gpio: Remove the usage of extcon_set_state() extcon: Remove the state_store() to prevent the wrong access extcon: Block the bit masking operation for cable state except for extcon core extcon: Add the extcon_type to gather each connector into five category extcon: Add the support for extcon property according to extcon type extcon: Add the support for the capability of each property extcon: Rename the extcon_set/get_state() to maintain the function naming pattern extcon: Add the synchronization extcon APIs to support the notification extcon: Add new EXTCON_DISP_HMD for Head-mounted Display device extcon: Add new EXTCON_CHG_WPT for Wireless Power Transfer device extcon: arizona: Remove the usage of extcon_update_state() extcon: adc-jack: Remove the usage of extcon_set_state() extcon: gpio: Remove the usage of extcon_set_state() extcon: Remove the state_store() to prevent the wrong access extcon: Block the bit masking operation for cable state except for extcon core extcon: Add the extcon_type to gather each connector into five category extcon: Add the support for extcon property according to extcon type extcon: Add the support for the capability of each property extcon: Rename the extcon_set/get_state() to maintain the function naming pattern extcon: Add the synchronization extcon APIs to support the notification extcon: Add new EXTCON_DISP_HMD for Head-mounted Display device extcon: Add new EXTCON_CHG_WPT for Wireless Power Transfer device extcon: Use the extcon_set_state_sync() instead of deprecated functions Charles Keepax (2): extcon: arizona: Remove unneeded semi-colon extcon: arizona: Remove unneeded semi-colon Chen-Yu Tsai (1): phy: sun4i-usb: Use spinlock to guard phyctl register access Chris Zhong (6): extcon: Add EXTCON_DISP_DP and the property for USB Type-C extcon: Add EXTCON_DISP_DP and the property for USB Type-C phy: Add USB Type-C PHY driver for rk3399 Documentation: bindings: add dt doc for Rockchip USB Type-C PHY phy: rockchip-typec: add pm runtime support extcon: Introduce EXTCON_PROP_DISP_H
[PATCH] Revert "usb: dwc3: gadget: use allocated/queued reqs for LST bit"
From: Ville Syrjälä
This reverts commit 55a0237f8f47957163125e20ee9260538c5c341c.
commit 55a0237f8f47 ("usb: dwc3: gadget: use allocated/queued reqs for
LST bit") causes my BYT FFRD8 with g_ether to behave poorly. ssh/scp
is very sluggish and can even stall entirely. Revert cures it.
Cc: Felipe Balbi
Cc: sta...@vger.kernel.org
Signed-off-by: Ville Syrjälä
---
drivers/usb/dwc3/gadget.c | 20 ++--
1 file changed, 6 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 122e64df2f4d..7362ff009a3a 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -894,8 +894,7 @@ static u32 dwc3_calc_trbs_left(struct dwc3_ep *dep)
}
static void dwc3_prepare_one_trb_sg(struct dwc3_ep *dep,
- struct dwc3_request *req, unsigned int trbs_left,
- unsigned int more_coming)
+ struct dwc3_request *req, unsigned int trbs_left)
{
struct usb_request *request = &req->request;
struct scatterlist *sg = request->sg;
@@ -912,8 +911,7 @@ static void dwc3_prepare_one_trb_sg(struct dwc3_ep *dep,
dma = sg_dma_address(s);
if (sg_is_last(s)) {
- if (usb_endpoint_xfer_int(dep->endpoint.desc) ||
- !more_coming)
+ if (list_is_last(&req->list, &dep->pending_list))
last = true;
chain = false;
@@ -934,8 +932,7 @@ static void dwc3_prepare_one_trb_sg(struct dwc3_ep *dep,
}
static void dwc3_prepare_one_trb_linear(struct dwc3_ep *dep,
- struct dwc3_request *req, unsigned int trbs_left,
- unsigned int more_coming)
+ struct dwc3_request *req, unsigned int trbs_left)
{
unsigned intlast = false;
unsigned intlength;
@@ -948,7 +945,7 @@ static void dwc3_prepare_one_trb_linear(struct dwc3_ep *dep,
last = true;
/* Is this the last request? */
- if (usb_endpoint_xfer_int(dep->endpoint.desc) || !more_coming)
+ if (list_is_last(&req->list, &dep->pending_list))
last = true;
dwc3_prepare_one_trb(dep, req, dma, length,
@@ -966,7 +963,6 @@ static void dwc3_prepare_one_trb_linear(struct dwc3_ep *dep,
static void dwc3_prepare_trbs(struct dwc3_ep *dep)
{
struct dwc3_request *req, *n;
- unsigned intmore_coming;
u32 trbs_left;
BUILD_BUG_ON_NOT_POWER_OF_2(DWC3_TRB_NUM);
@@ -975,15 +971,11 @@ static void dwc3_prepare_trbs(struct dwc3_ep *dep)
if (!trbs_left)
return;
- more_coming = dep->allocated_requests - dep->queued_requests;
-
list_for_each_entry_safe(req, n, &dep->pending_list, list) {
if (req->request.num_mapped_sgs > 0)
- dwc3_prepare_one_trb_sg(dep, req, trbs_left--,
- more_coming);
+ dwc3_prepare_one_trb_sg(dep, req, trbs_left--);
else
- dwc3_prepare_one_trb_linear(dep, req, trbs_left--,
- more_coming);
+ dwc3_prepare_one_trb_linear(dep, req, trbs_left--);
if (!trbs_left)
return;
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager (tcpm)
Hi Guenter, On Tue, Aug 23, 2016 at 02:10:50PM -0700, Guenter Roeck wrote: > +config TYPEC_TCPM > + tristate "USB Type-C Port Controller Manager" > + select TYPEC > + help > + The Type-C Port Controller Manager provides a USB PD and USB Type-C > + state machine for use with Type-C Port Controllers. Since this is "tristate", don't forget to add MODULE_*() stuff in the next version. Thanks, -- heikki -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422
Hi, On Di, 2016-09-20 at 23:12 +0200, Michael Niewöhner wrote: > > > Hi guys, > > > > > > > > > > > > > Hi All > > > > > > Adding Vivek Gautam. > > > > > > On 29 August 2016 at 16:35, Michael Niewöhner > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Mathias, > > > > > On Mo, 2016-08-29 at 13:59 +0300, Mathias Nyman wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 29.08.2016 10:28, Felipe Balbi wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > Michael Niewöhner writes: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [1.] One line summary of the problem: > > > > > > > > > > > DWC3 USB 3.0 not working on Odroid-XU4 with > > > > > > Exynos 5422 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [2.] Full description of the problem/report: > > > > > > > > > > > No usb 3.0 devices are being detected when > > > > > > attached while USB > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2.0 > > > > > > > > > > > devices work on the same port. > > > > > > > > > > > USB 3.0 works after applying patches [9.1] and > > > > > > [9.2], but > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > seems > > > > > > > > > > > to be > > > > > > > > > > > buggy. The usb hub is redetected every time an > > > > > > usb device is > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > attached. > > > > > > > > > > > > > > > > > > dwc3 is host, which means it's actually XHCI :-) > > > > > > > > > > > > > > > > > > Adding Mathias > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > dmesg: > > > > > > > > > > > [ 192.287080] usb 3-1.2: USB disconnect, device > > > > > > number 7 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [ 210.370699] hub 3-1:1.0: hub_ext_port_status > > > > > > failed (err = > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -71) > > > > > > > > > > > > > > Looks like the hub GetPortStatus request fails with > > > > protocol > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > error. > > > > > > > > > > > > > > Reading xhci root hub port status is mostly just register > > > > reads > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > and > > > > > > > writes. It > > > > > > > shouldn't include any actual transfers that could return > > > > -EPROTO > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > So this is not the root hub? but a external or integrated > > > > on your > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > board, right? > > > > > > > > > > > > > > The protocol error -71 is returned at transfer errors or > > > > if > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > device > > > > > > > stalled. > > > > > > > > > > > > > > Adding more xhci debugging options could show something: > > > > > > > echo -n 'module xhci_hcd =p' > > > > > > > > /sys/kernel/debug/dynamic_debug/control > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [9.] Other notes, patches, fixes, workarounds: > > > > > > > > > > > [9.1] https://lkml.org/lkml/2014/4/28/234 > > > > > > > > > > > [9.2] https://lkml.org/lkml/2015/2/2/259 > > > > > > > > > > > > > > The additional patches that makes things somehow work > > > > involve
Re: [RFC/PATCH 17/45] usb: gadget: udc: atmel: make use of new usb_endpoint_maxp_mult()
Le 28/09/2016 à 15:05, Felipe Balbi a écrit : > We have introduced a helper to calculate multiplier > value from wMaxPacketSize. Start using it. > > Cc: Nicolas Ferre Acked-by: Nicolas Ferre > Cc: > Signed-off-by: Felipe Balbi > --- > drivers/usb/gadget/udc/atmel_usba_udc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c > b/drivers/usb/gadget/udc/atmel_usba_udc.c > index 45bc997d0711..c57012b1ddf4 100644 > --- a/drivers/usb/gadget/udc/atmel_usba_udc.c > +++ b/drivers/usb/gadget/udc/atmel_usba_udc.c > @@ -573,7 +573,7 @@ usba_ep_enable(struct usb_ep *_ep, const struct > usb_endpoint_descriptor *desc) >* Bits 11:12 specify number of _additional_ >* transactions per microframe. >*/ > - nr_trans = ((usb_endpoint_maxp(desc) >> 11) & 3) + 1; > + nr_trans = usb_endpoint_maxp_mult(desc); > if (nr_trans > 3) > return -EINVAL; > > -- Nicolas Ferre -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 35/45] usb: gadget: udc: atmel: remove unnecessary & operation
Le 28/09/2016 à 15:05, Felipe Balbi a écrit : > Now that usb_endpoint_maxp() only returns the lowest > 11 bits from wMaxPacketSize, we can remove the & > operation from this driver. > > Cc: Nicolas Ferre Acked-by: Nicolas Ferre > Cc: > Signed-off-by: Felipe Balbi > --- > drivers/usb/gadget/udc/atmel_usba_udc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c > b/drivers/usb/gadget/udc/atmel_usba_udc.c > index c57012b1ddf4..125680db9379 100644 > --- a/drivers/usb/gadget/udc/atmel_usba_udc.c > +++ b/drivers/usb/gadget/udc/atmel_usba_udc.c > @@ -529,7 +529,7 @@ usba_ep_enable(struct usb_ep *_ep, const struct > usb_endpoint_descriptor *desc) > > DBG(DBG_GADGET, "%s: ep_enable: desc=%p\n", ep->ep.name, desc); > > - maxpacket = usb_endpoint_maxp(desc) & 0x7ff; > + maxpacket = usb_endpoint_maxp(desc); > > if (((desc->bEndpointAddress & USB_ENDPOINT_NUMBER_MASK) != ep->index) > || ep->index == 0 > -- Nicolas Ferre -- 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 hot-plug not working (ASUS TP301UA-C4028T)
On 03.10.2016 13:09, Mathias Nyman wrote:
I'm writing a workaround that will disable runtime PM for the xhci controller
In case we are about to put (keep) it in D0 without PME# wake support.
I also learned the lspci -vv might wake up the controller from D3cold so it's
also
possible that PME# is failing in D3Cold.
Could you do two more things to verify the D state so that I fix the right
issue:
1. check the D state from sysfs, on-battery, in state where usb devices are not
detected:
cat /sys/bus/pci/devices/\:00\:14.0/firmware_node/power_state
2. send the DSDT table of your machine, it includes the ACPI methods that
dictate the possible D states
copy /sys/firmware/acpi/tables/DSDT to a file and send it (a link to it, or
attachment) to me, It's binary.
Thanks, I got the info off-list, and device is really in D0 and ACPI DSDT
(provided by firmware) is
the one enforcing it:
From DSDT:
Scope (_SB.PCI0)
{
Device (XHC)
{
...
Method (_S0W, 0, NotSerialized) // _S0W: S0 Device Wake State
{
If (LEqual (XFLT, Zero))
{
Return (Zero)
}
Else
{
Return (Zero)
}
}
_S0W will return the deepest allowed runtime suspend D state, always zero in
this case.
Normally if driver has all the needed quirks in place then XFLT == 3 (As linux
xhci-hcd does)
then _S0W usually returns "3". But with this firmware _S0W always returns zero.
checking XFLT is useless.
Anyways, I'll write a workaround for this case in xhci, disabling runtime PM if
lowest runtime sleep state (highest D state) is D0 and PME# is disabled in D0.
-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: USB hot-plug not working (ASUS TP301UA-C4028T)
On 01.10.2016 11:34, Pierre de Villemereuil wrote: Hi Mathias, FYI, turned out to be pretty easy. I got the tip from deano_ferrari without even asking: https://forums.opensuse.org/showthread.php/519926-No-USB-device-detected? p=2794434#post2794434 Simply adding this to GRUB options while launching kernel: usbcore.autosuspend=-1 disables USB suspends and fixes the problem (well, "workarounds" it). Weirdly enough, I still get "auto" on battery with: cat /sys/bus/pci/devices/\:00\:14.0/power/control Though I get "-1" from this: cat /sys/module/usbcore/parameters/autosuspend Not sure any of this is relevant, but I guess sharing information can't hurt. It's probably laptop-mode-tools (or equivalent) that keeps writing over that value. I'm writing a workaround that will disable runtime PM for the xhci controller In case we are about to put (keep) it in D0 without PME# wake support. I also learned the lspci -vv might wake up the controller from D3cold so it's also possible that PME# is failing in D3Cold. Could you do two more things to verify the D state so that I fix the right issue: 1. check the D state from sysfs, on-battery, in state where usb devices are not detected: cat /sys/bus/pci/devices/\:00\:14.0/firmware_node/power_state 2. send the DSDT table of your machine, it includes the ACPI methods that dictate the possible D states copy /sys/firmware/acpi/tables/DSDT to a file and send it (a link to it, or attachment) to me, It's binary. -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 1/2] usb: musb: Fix hardirq-safe hardirq-unsafe lock order error
Hi Tony,
Thank you for the patch.
On Friday 30 Sep 2016 11:10:09 Tony Lindgren wrote:
> If we configure musb with 2430 glue as a peripheral, and then rmmod
> omap2430 module, we'll get the following error:
>
> [ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ]
> ...
> rmmod/413 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
> (&phy->mutex){+.+.+.}, at: [] phy_power_off+0x1c/0xb8
> [ 204.678710]
>and this task is already holding:
> (&(&musb->lock)->rlock){-.-...}, at: []
> musb_gadget_stop+0x24/0xec [musb_hdrc]
> which would create a new lock dependency:
> (&(&musb->lock)->rlock){-.-...} -> (&phy->mutex){+.+.+.}
> ...
>
> This is because some glue layers expect musb_platform_enable/disable
> to be called with spinlock held, and 2430 glue layer has USB PHY on
> the I2C bus using a mutex.
>
> We could fix the glue layers to take the spinlock, but we still have
> a problem of musb_plaform_enable/disable being called in an unbalanced
> manner. So that would still lead into USB PHY enable/disable related
> problems for omap2430 glue layer.
>
> While it makes sense to only enable USB PHY when needed from PM point
> of view, in this case we just can't do it yet without breaking things.
> So let's just revert phy_enable/disable related changes instead and
> reconsider this after we have fixed musb_platform_enable/disable to
> be balanced.
>
> Fixes: a83e17d0f73b ("usb: musb: Improve PM runtime and phy handling
> for 2430 glue layer")
> Signed-off-by: Tony Lindgren
Reviewed-by: Laurent Pinchart
> ---
> drivers/usb/musb/omap2430.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
> --- a/drivers/usb/musb/omap2430.c
> +++ b/drivers/usb/musb/omap2430.c
> @@ -287,6 +287,7 @@ static int omap2430_musb_init(struct musb *musb)
> }
> musb->isr = omap2430_musb_interrupt;
> phy_init(musb->phy);
> + phy_power_on(musb->phy);
>
> l = musb_readl(musb->mregs, OTG_INTERFSEL);
>
> @@ -323,8 +324,6 @@ static void omap2430_musb_enable(struct musb *musb)
> struct musb_hdrc_platform_data *pdata = dev_get_platdata(dev);
> struct omap_musb_board_data *data = pdata->board_data;
>
> - if (!WARN_ON(!musb->phy))
> - phy_power_on(musb->phy);
>
> switch (glue->status) {
>
> @@ -361,9 +360,6 @@ static void omap2430_musb_disable(struct musb *musb)
> struct device *dev = musb->controller;
> struct omap2430_glue *glue = dev_get_drvdata(dev->parent);
>
> - if (!WARN_ON(!musb->phy))
> - phy_power_off(musb->phy);
> -
> if (glue->status != MUSB_UNKNOWN)
> omap_control_usb_set_mode(glue->control_otghs,
> USB_MODE_DISCONNECT);
> @@ -375,6 +371,7 @@ static int omap2430_musb_exit(struct musb *musb)
> struct omap2430_glue *glue = dev_get_drvdata(dev->parent);
>
> omap2430_low_level_exit(musb);
> + phy_power_off(musb->phy);
> phy_exit(musb->phy);
> musb->phy = NULL;
> cancel_work_sync(&glue->omap_musb_mailbox_work);
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/7] tty: vgacon+sisusb, move scrolldelta to a common helper
The code is mirrorred in scrolldelta implementations of both vgacon
and sisusb. Let's move the code to a separate helper where we will
perform a common cleanup and further changes.
While we are moving the code, make it linear and save one indentation
level. This is done by returning from the "!lines" then-branch
immediatelly. This allows flushing the else-branch 1 level to the
left, obviously.
Few more new lines and comments were added too.
And do not forget to export the helper function given sisusb can be
built as module.
Signed-off-by: Jiri Slaby
Cc: Thomas Winischhofer
Cc: Tomi Valkeinen
Cc:
Cc:
---
drivers/tty/vt/vt.c | 38 +
drivers/usb/misc/sisusbvga/sisusb_con.c | 37 ++--
drivers/video/console/vgacon.c | 27 ++-
include/linux/vt_kern.h | 2 ++
4 files changed, 44 insertions(+), 60 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index ecabed91f444..397c72c2fcb8 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -4275,6 +4275,44 @@ void vcs_scr_updated(struct vc_data *vc)
notify_update(vc);
}
+void vc_scrolldelta_helper(struct vc_data *c, int lines,
+ unsigned int rolled_over, void *base, unsigned int size)
+{
+ unsigned long ubase = (unsigned long)base;
+ int margin = c->vc_size_row * 4;
+ int ul, we, p, st;
+
+ /* Turn scrollback off */
+ if (!lines) {
+ c->vc_visible_origin = c->vc_origin;
+ return;
+ }
+
+ /* Do we have already enough to allow jumping from 0 to the end? */
+ if (rolled_over > (c->vc_scr_end - ubase) + margin) {
+ ul = c->vc_scr_end - ubase;
+ we = rolled_over + c->vc_size_row;
+ } else {
+ ul = 0;
+ we = size;
+ }
+
+ p = (c->vc_visible_origin - ubase - ul + we) % we +
+ lines * c->vc_size_row;
+ st = (c->vc_origin - ubase - ul + we) % we;
+
+ /* Only a little piece would be left? Show all incl. the piece! */
+ if (st < 2 * margin)
+ margin = 0;
+ if (p < margin)
+ p = 0;
+ if (p > st - margin)
+ p = st;
+
+ c->vc_visible_origin = ubase + (p + ul) % we;
+}
+EXPORT_SYMBOL_GPL(vc_scrolldelta_helper);
+
/*
* Visible symbols for modules
*/
diff --git a/drivers/usb/misc/sisusbvga/sisusb_con.c
b/drivers/usb/misc/sisusbvga/sisusb_con.c
index 6331965daa0b..4b5777ec1501 100644
--- a/drivers/usb/misc/sisusbvga/sisusb_con.c
+++ b/drivers/usb/misc/sisusbvga/sisusb_con.c
@@ -686,8 +686,6 @@ static void
sisusbcon_scrolldelta(struct vc_data *c, int lines)
{
struct sisusb_usb_data *sisusb;
- int margin = c->vc_size_row * 4;
- int ul, we, p, st;
sisusb = sisusb_get_sisusb_lock_and_check(c->vc_num);
if (!sisusb)
@@ -700,39 +698,8 @@ sisusbcon_scrolldelta(struct vc_data *c, int lines)
return;
}
- if (!lines) /* Turn scrollback off */
- c->vc_visible_origin = c->vc_origin;
- else {
-
- if (sisusb->con_rolled_over >
- (c->vc_scr_end - sisusb->scrbuf) + margin) {
-
- ul = c->vc_scr_end - sisusb->scrbuf;
- we = sisusb->con_rolled_over + c->vc_size_row;
-
- } else {
-
- ul = 0;
- we = sisusb->scrbuf_size;
-
- }
-
- p = (c->vc_visible_origin - sisusb->scrbuf - ul + we) % we +
- lines * c->vc_size_row;
-
- st = (c->vc_origin - sisusb->scrbuf - ul + we) % we;
-
- if (st < 2 * margin)
- margin = 0;
-
- if (p < margin)
- p = 0;
-
- if (p > st - margin)
- p = st;
-
- c->vc_visible_origin = sisusb->scrbuf + (p + ul) % we;
- }
+ vc_scrolldelta_helper(c, lines, sisusb->con_rolled_over,
+ (void *)sisusb->scrbuf, sisusb->scrbuf_size);
sisusbcon_set_start_address(sisusb, c);
diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c
index 4c54a873452e..ede6a5a85ccd 100644
--- a/drivers/video/console/vgacon.c
+++ b/drivers/video/console/vgacon.c
@@ -332,31 +332,8 @@ static void vgacon_restore_screen(struct vc_data *c)
static void vgacon_scrolldelta(struct vc_data *c, int lines)
{
- if (!lines) /* Turn scrollback off */
- c->vc_visible_origin = c->vc_origin;
- else {
- int margin = c->vc_size_row * 4;
- int ul, we, p, st;
-
- if (vga_rolled_over >
- (c->vc_scr_end - vga_vram_base) + margin) {
- ul = c->vc_scr_end - vga_vram_base;
- we = v
[PATCH 1/7] tty: vt, cleanup and document con_scroll
Scrolling helpers scrup and scrdown both accept 'top' and 'bottom' as
unsigned int. Number of lines 'nr' is accepted as int, but all callers
pass down unsigned too. So change the type of 'nr' to unsigned too.
Now, promote unsigned int from the helpers up to the con_scroll
hook which actually accepted all those as signed int.
Next, the 'dir' parameter can have only two values and we define
constants for that: SM_UP and SM_DOWN. Switch them to enum and do
proper type checking on 'dir' too.
Finally, document the behaviour of the hook.
Signed-off-by: Jiri Slaby
Cc: Thomas Winischhofer
Cc: Tomi Valkeinen
Cc: "James E.J. Bottomley"
Cc: Helge Deller
Cc:
Cc:
Cc:
---
drivers/tty/vt/vt.c | 6 --
drivers/usb/misc/sisusbvga/sisusb_con.c | 18 ++
drivers/video/console/fbcon.c | 18 --
drivers/video/console/mdacon.c | 7 ---
drivers/video/console/newport_con.c | 8
drivers/video/console/sticon.c | 7 ---
drivers/video/console/vgacon.c | 12 +---
include/linux/console.h | 16 +++-
8 files changed, 50 insertions(+), 42 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index e2cad4c2ba5a..a0ccb3950a50 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -315,7 +315,8 @@ void schedule_console_callback(void)
schedule_work(&console_work);
}
-static void scrup(struct vc_data *vc, unsigned int t, unsigned int b, int nr)
+static void scrup(struct vc_data *vc, unsigned int t, unsigned int b,
+ unsigned int nr)
{
unsigned short *d, *s;
@@ -332,7 +333,8 @@ static void scrup(struct vc_data *vc, unsigned int t,
unsigned int b, int nr)
vc->vc_size_row * nr);
}
-static void scrdown(struct vc_data *vc, unsigned int t, unsigned int b, int nr)
+static void scrdown(struct vc_data *vc, unsigned int t, unsigned int b,
+ unsigned int nr)
{
unsigned short *s;
unsigned int step;
diff --git a/drivers/usb/misc/sisusbvga/sisusb_con.c
b/drivers/usb/misc/sisusbvga/sisusb_con.c
index 460cebf322e3..6331965daa0b 100644
--- a/drivers/usb/misc/sisusbvga/sisusb_con.c
+++ b/drivers/usb/misc/sisusbvga/sisusb_con.c
@@ -808,9 +808,10 @@ sisusbcon_cursor(struct vc_data *c, int mode)
mutex_unlock(&sisusb->lock);
}
-static int
+static bool
sisusbcon_scroll_area(struct vc_data *c, struct sisusb_usb_data *sisusb,
- int t, int b, int dir, int lines)
+ unsigned int t, unsigned int b, enum con_scroll dir,
+ unsigned int lines)
{
int cols = sisusb->sisusb_num_columns;
int length = ((b - t) * cols) * 2;
@@ -852,8 +853,9 @@ sisusbcon_scroll_area(struct vc_data *c, struct
sisusb_usb_data *sisusb,
}
/* Interface routine */
-static int
-sisusbcon_scroll(struct vc_data *c, int t, int b, int dir, int lines)
+static bool
+sisusbcon_scroll(struct vc_data *c, unsigned int t, unsigned int b,
+ enum con_scroll dir, unsigned int lines)
{
struct sisusb_usb_data *sisusb;
u16 eattr = c->vc_video_erase_char;
@@ -870,17 +872,17 @@ sisusbcon_scroll(struct vc_data *c, int t, int b, int
dir, int lines)
*/
if (!lines)
- return 1;
+ return true;
sisusb = sisusb_get_sisusb_lock_and_check(c->vc_num);
if (!sisusb)
- return 0;
+ return false;
/* sisusb->lock is down */
if (sisusb_is_inactive(c, sisusb)) {
mutex_unlock(&sisusb->lock);
- return 0;
+ return false;
}
/* Special case */
@@ -971,7 +973,7 @@ sisusbcon_scroll(struct vc_data *c, int t, int b, int dir,
int lines)
mutex_unlock(&sisusb->lock);
- return 1;
+ return true;
}
/* Interface routine */
diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
index b87f5cfdaea5..a44f5627b82a 100644
--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -164,8 +164,6 @@ static void fbcon_putcs(struct vc_data *vc, const unsigned
short *s,
int count, int ypos, int xpos);
static void fbcon_clear_margins(struct vc_data *vc, int bottom_only);
static void fbcon_cursor(struct vc_data *vc, int mode);
-static int fbcon_scroll(struct vc_data *vc, int t, int b, int dir,
- int count);
static void fbcon_bmove(struct vc_data *vc, int sy, int sx, int dy, int dx,
int height, int width);
static int fbcon_switch(struct vc_data *vc);
@@ -1795,15 +1793,15 @@ static inline void fbcon_softback_note(struct vc_data
*vc, int t,
softback_curr = softback_in;
}
-static int fbcon_scroll(struct vc_data *vc, int t, int b, int dir,
- int count)
+static bool fbcon_scroll(struct vc_data *vc, unsigned int t, unsigned int b,
+
Re: USB will randomly stop working
On Mon, Oct 03, 2016 at 12:58:48AM -0700, Ashton Holmes wrote: > This happened back in the 4.8 release candidate and I thought it would > be fixed when the kernel went stable but I'm still having the issue. > The kernel seems to randomly reset my USB controller or do something > to that effect. Basically all my USB devices stop will randomly stop > working and I have to force reboot the system to get them to come back > only to have them work for 5 minutes or so before doing it again. I've > rolled back to 4.7.6 so I can use my system but 4.8 just doesn't seem > to want to work with USB. I've attached a segment from my syslog that > I think shows the issue. > Oct 2 22:23:31 user-desktop kernel: [ 143.307247] ohci-pci :00:12.0: > HcDoneHead not written back; disabled > Oct 2 22:23:31 user-desktop kernel: [ 143.307251] ohci-pci :00:12.0: HC > died; cleaning up > Oct 2 22:23:31 user-desktop kernel: [ 143.307292] usb 10-1: USB disconnect, > device number 2 Ick, that's not good, anything right before these lines? And you can always let us know that we broke something during the -rc releases, that way we have a chance to fix it :) Along those lines, any chance you can run 'git bisect' to find the problem patch? 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
USB will randomly stop working
This happened back in the 4.8 release candidate and I thought it would be fixed when the kernel went stable but I'm still having the issue. The kernel seems to randomly reset my USB controller or do something to that effect. Basically all my USB devices stop will randomly stop working and I have to force reboot the system to get them to come back only to have them work for 5 minutes or so before doing it again. I've rolled back to 4.7.6 so I can use my system but 4.8 just doesn't seem to want to work with USB. I've attached a segment from my syslog that I think shows the issue. Oct 2 22:23:31 user-desktop kernel: [ 143.307247] ohci-pci :00:12.0: HcDoneHead not written back; disabled Oct 2 22:23:31 user-desktop kernel: [ 143.307251] ohci-pci :00:12.0: HC died; cleaning up Oct 2 22:23:31 user-desktop kernel: [ 143.307292] usb 10-1: USB disconnect, device number 2 Oct 2 22:23:31 user-desktop gdm-Xorg-:0[701]: (II) config/udev: removing device Logitech G700s Rechargeable Gaming Mouse Oct 2 22:23:31 user-desktop gdm-Xorg-:0[701]: (II) evdev: Logitech G700s Rechargeable Gaming Mouse: Close Oct 2 22:23:31 user-desktop gdm-Xorg-:0[701]: (II) UnloadModule: "evdev" Oct 2 22:23:31 user-desktop acpid: input device has been disconnected, fd 4 Oct 2 22:23:31 user-desktop gdm-Xorg-:0[701]: (II) config/udev: removing device Logitech G700s Rechargeable Gaming Mouse Oct 2 22:23:31 user-desktop pulseaudio[804]: Got POLLNVAL from ALSA Oct 2 22:23:31 user-desktop pulseaudio[804]: Could not recover from POLLERR|POLLNVAL|POLLHUP with snd_pcm_prepare(): No such device Oct 2 22:23:31 user-desktop kernel: [ 143.427525] usb 10-2: USB disconnect, device number 3 Oct 2 22:23:31 user-desktop gnome-session[720]: (gnome-settings-daemon:778): media-keys-plugin-WARNING **: Unable to get default sink Oct 2 22:23:31 user-desktop gdm-Xorg-:0[701]: (II) evdev: Logitech G700s Rechargeable Gaming Mouse: Close Oct 2 22:23:31 user-desktop gdm-Xorg-:0[701]: (II) UnloadModule: "evdev" Oct 2 22:23:31 user-desktop acpid: input device has been disconnected, fd 15 Oct 2 22:23:31 user-desktop gdm-Xorg-:0[701]: (II) config/udev: removing device Logitech Logitech G933 Gaming Wireless Headset Oct 2 22:23:31 user-desktop kernel: [ 143.483518] usb 10-4: USB disconnect, device number 4 Oct 2 22:23:31 user-desktop gdm-Xorg-:0[701]: (II) evdev: Logitech Logitech G933 Gaming Wireless Headset: Close Oct 2 22:23:31 user-desktop gdm-Xorg-:0[701]: (II) UnloadModule: "evdev" Oct 2 22:23:31 user-desktop gdm-Xorg-:0[701]: (II) config/udev: removing device Logitech USB Receiver Oct 2 22:23:31 user-desktop gdm-Xorg-:0[701]: (II) evdev: Logitech USB Receiver: Close Oct 2 22:23:31 user-desktop gdm-Xorg-:0[701]: (II) UnloadModule: "evdev" Oct 2 22:23:31 user-desktop acpid: input device has been disconnected, fd 21 Oct 2 22:23:31 user-desktop gdm-Xorg-:0[701]: (II) config/udev: removing device Logitech USB Receiver Oct 2 22:23:31 user-desktop kernel: [ 143.623574] usb 10-5: USB disconnect, device number 5 Oct 2 22:23:31 user-desktop gdm-Xorg-:0[701]: (II) evdev: Logitech USB Receiver: Close Oct 2 22:23:31 user-desktop gdm-Xorg-:0[701]: (II) UnloadModule: "evdev" Oct 2 22:23:31 user-desktop acpid: input device has been disconnected, fd 22 Oct 2 22:23:31 user-desktop gdm-Xorg-:0[701]: (II) config/udev: removing device Logitech Gaming Keyboard G910 Oct 2 22:23:31 user-desktop gdm-Xorg-:0[701]: (II) evdev: Logitech Gaming Keyboard G910: Close Oct 2 22:23:31 user-desktop gdm-Xorg-:0[701]: (II) UnloadModule: "evdev" Oct 2 22:23:31 user-desktop acpid: input device has been disconnected, fd 23 Oct 2 22:23:31 user-desktop gdm-Xorg-:0[701]: (II) config/udev: removing device Logitech Gaming Keyboard G910 Oct 2 22:23:31 user-desktop gdm-Xorg-:0[701]: (II) evdev: Logitech Gaming Keyboard G910: Close Oct 2 22:23:31 user-desktop gdm-Xorg-:0[701]: (II) UnloadModule: "evdev"
