Re: Slow I/O on USB media
Il giorno mer, 05/06/2019 alle 19.39 +0200, Greg KH ha scritto: > On Wed, Jun 05, 2019 at 06:23:58PM +0200, Andrea Vai wrote: > [...] > In ssh I manually mount the media, > then > > run > > > > touch begin > > date > > > > date > > touch end > > That tests nothing other than the size of the memory in your system > :( > > You have to flush the data out to the device fully in order to > properly > measure device throughput. Calling 'touch' does not do that. > > > If I use the DE (where the media is mounted automatically) I used > to > > "eject" the media after the copy finished, and took note of the > time > > used until the media was correctly "ejected" (and, so, unmounted). > > eject/unmount is good. > > > Anyway, I know that I can do all of this in a better way, and will > let > > you know. > > Yes, please do so, your steps above do not show much. so, just to be sure now, here is my test script: touch inizio date mount UUID="6a9d3c05-6758-49c0-a46e-6ce221478eb3" /mnt/pendrive cp /NoBackup/buttare/ubuntu-14.04.5-desktop-i386.iso /mnt/pendrive umount /mnt/pendrive date touch fine can you please confirm (if) it's fine? > > And you need to get your auto-mount out of the way, as who knows > what > options your device is being mounted with (i.e. sync or no > sync). You > have to control that yourself in order to be sure. yes, I disabled the auto-mount. Furthermore, is there any option I need to specify to the mount command (i.e., as you say, sync or no sync)? thanks, bye Andrea
Re: Slow I/O on USB media
Il giorno mer, 05/06/2019 alle 19.39 +0200, Greg KH ha scritto: > On Wed, Jun 05, 2019 at 06:23:58PM +0200, Andrea Vai wrote: > > Hi, > > Il giorno mer, 05/06/2019 alle 16.55 +0200, Greg KH ha scritto: > > > On Wed, Jun 05, 2019 at 09:36:04AM +0200, Andrea Vai wrote: > > > > Hi, > > > > Il giorno mar, 04/06/2019 alle 07.43 +0200, Greg KH ha > scritto: > > > > > On Mon, Jun 03, 2019 at 01:13:48PM +0200, Andrea Vai wrote: > > > > > > Il giorno gio, 30/05/2019 alle 06.25 -0700, Greg KH ha > > > scritto: > > > > > > > [...] > > > > > > Hi, > > > > > > > > > > > > > Any chance you can use 'git bisect' to find the > offending > > > > > commit? > > > > > > Yes, I am doing it as I managed to build the kernel from > > > source > > > > > > > > > > Great! What did you find? > > > > > > > > # first bad commit: [534903d60376b4989b76ec445630aa10f2bc3043] > > > > drm/atomic: Use explicit old crtc state in > > > > drm_atomic_add_affected_planes() > > > > > > > > By the way, as I am not expert, is there a way to double-check > > > that I > > > > bisected correctly? (such as, e.g., test with the version > before > > > this > > > > one, and then with this commit applied?) > > > > > > How exactly are you "testing" this? > > > > > > I would recommend a script that does something like: > > > mount the disk somewhere > > > copy a big file to it > > > unmount the disk > > > > > > testing how long the whole process takes, especially the > 'unmount' > > > is > > > important. Are you doing that? > > > > Well, not exactly, and thank you for pointing me out. I am doing > the > > job in two ways, from the DE (when I am located at the PC), or in > an > > ssh session when I am away. In ssh I manually mount the media, > then > > run > > > > touch begin > > date > > > > date > > touch end > > That tests nothing other than the size of the memory in your system > :( > > You have to flush the data out to the device fully in order to > properly > measure device throughput. Calling 'touch' does not do that. > > > If I use the DE (where the media is mounted automatically) I used > to > > "eject" the media after the copy finished, and took note of the > time > > used until the media was correctly "ejected" (and, so, unmounted). > > eject/unmount is good. > > > Anyway, I know that I can do all of this in a better way, and will > let > > you know. > > Yes, please do so, your steps above do not show much. > > excuse me, another question: since I get the good behavior with kernel 4.20.13 (installed from my distro packages), is it correct to run at first git bisect start git bisect good v4.20.13 , then build the latest kernel, test it, set it as bad (as far as I can expect) and go on with following tests? Many thanks, Andrea
Re: kernel NULL pointer dereference, ucsi bug
Thanks a lot! Now I understand how to work with bisect in general.
However, its log is unlikely to be of help because I use my distro
tools to make a kernel package. So I dropped down into the merge
commit and for now I am here:
index : kernel/git/davem/net-next.git
commit - time&date - works or not
80f232121b69cc69a31ccb2b38c1665d770b0710 - 2019-05-07 22:03:58 -0700 - y
5d438e200215f61ca6a7aa69f3c4e035ac54d8ee - 2019-04-25 11:03:52 +0200 - y
6f6a407a591ebe3e4c6bd2329b29862b3980a3ca - 2019-05-03 18:00:15 +0200 -
bug introduced? Not sure:
Jun 06 18:57:33 kernel: BUG: unable to handle kernel NULL pointer
dereference at 0370
But no log-in issues which were preventing me from logging in as whole
merge 132d68d37d33f1d0b9c1f507c8b4d64c27ecec8a did, so there must be
something else after this commit too. For now I marked it as "bad".
e823d948b7e53dc982c867ac4ce7877fc0418897 - 2019-04-30 17:55:08 +0200 -
this is being built at the moment.
Bisect log, just in case:
git bisect start
# bad: [132d68d37d33f1d0b9c1f507c8b4d64c27ecec8a] Merge tag
'usb-5.2-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
git bisect bad 132d68d37d33f1d0b9c1f507c8b4d64c27ecec8a
# good: [86dc59e39031fb0d366d5b1f92db015b24bef70b] net: dsa: sja1105:
Make 'sja1105et_regs' and 'sja1105pqrs_regs' static
git bisect good 86dc59e39031fb0d366d5b1f92db015b24bef70b
# good: [80f232121b69cc69a31ccb2b38c1665d770b0710] Merge
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next
git bisect good 80f232121b69cc69a31ccb2b38c1665d770b0710
# good: [5d438e200215f61ca6a7aa69f3c4e035ac54d8ee] usb: typec: ucsi:
ccg: add get_fw_info function
git bisect good 5d438e200215f61ca6a7aa69f3c4e035ac54d8ee
# bad: [6f6a407a591ebe3e4c6bd2329b29862b3980a3ca] Merge tag
'usb-serial-5.2-rc1' of
https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into
usb-next
git bisect bad 6f6a407a591ebe3e4c6bd2329b29862b3980a3ca
Have a good day,
Vladimir
чт, 6 июн. 2019 г. в 02:59, Greg KH :
>
> On Wed, Jun 05, 2019 at 04:36:23PM +1000, Vladimir Yerilov wrote:
> > Good day Mr. Kroah-Hartman,
> >
> > I've found the culprit commit. It took a while though but now I'm sure:
> >
> > commit - brief decription - time - works (y) or not (n)
> > 670784fb4ebe54434e263837390e358405031d9e - rc1 2019-05-20
> > e260ad01f0aa9e96b5386d5cd7184afd949dc457 - rc0 2019-05-14 19:52:51 -0700 n
> > 8ea5b2abd07e2280a332bd9c1a7f4dd15b9b6c13 - rc0 2019-05-09 19:35:41 -0700 n
> > 54516da1ea859dd4f56ebba2e483d2df9d7c8a32 - rc0 2019-05-05 21:58:36 -0700 y
> > 71ae5fc87c34ecbdca293c2a5c563d6be2576558 - rc0 2019-05-06 20:29:45 -0700 y
> > 80f232121b69cc69a31ccb2b38c1665d770b0710 - rc0 2019-05-07 22:03:58 -0700 y
> > a2d635decbfa9c1e4ae15cb05b68b2559f7f827c - rc0 2019-05-08 21:35:19 -0700 n
> > 132d68d37d33f1d0b9c1f507c8b4d64c27ecec8a - rc0 2019-05-08 10:03:52 -0700 n
> > 86dc59e39031fb0d366d5b1f92db015b24bef70b - rc0 2019-05-08 09:46:44 -0700 y
> >
> > So 86dc59e39031fb0d366d5b1f92db015b24bef70b is the last working for
> > me, and 132d68d37d33f1d0b9c1f507c8b4d64c27ecec8a is the breaking one:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.2-rc3&id=132d68d37d33f1d0b9c1f507c8b4d64c27ecec8a
>
> 132d68d37d33 ("Merge tag 'usb-5.2-rc1' of
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb")
> is a merge point, which is odd, you should be able to drop down into
> that and find the exact wrong commit.
>
> what does 'git bisect log' show?
>
> thanks,
>
> greg k-h
--
Best regards,
Vladimir Yerilov
Re: [PATCH v2] usb: dwc2: Use generic PHY width in params setup
Hi All,
On 2019-05-31 14:44, Minas Harutyunyan wrote:
> On 5/9/2019 1:16 PM, Jules Maselbas wrote:
>> Setting params.phy_utmi_width in dwc2_lowlevel_hw_init() is pointless
>> since
>> it's value will be overwritten by dwc2_init_params().
>>
>> This change make sure to take in account the generic PHY width
>> information
>> during paraminitialisation, done in dwc2_set_param_phy_utmi_width().
>>
>> By doing so, the phy_utmi_width params can still be overrided by
>> devicetree specific params and will also be checked against hardware
>> capabilities.
>>
>> Fixes: 707d80f0a3c5 ("usb: dwc2: gadget: Replace phyif with
>> phy_utmi_width")
>> Tested-by: Marek Szyprowski
>> Signed-off-by: Jules Maselbas
>
> Acked-by: Minas Harutyunyan
Gentle reminder, Felipe, could you take this to the fixes for v5.2?
>> ---
>> v2: Fix typo in commit message. Add Fixes and Tested-by tags.
>> ---
>> drivers/usb/dwc2/params.c | 9 +
>> drivers/usb/dwc2/platform.c | 9 -
>> 2 files changed, 9 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
>> index 6900eea57526..5949262ff669 100644
>> --- a/drivers/usb/dwc2/params.c
>> +++ b/drivers/usb/dwc2/params.c
>> @@ -253,6 +253,15 @@ static void dwc2_set_param_phy_utmi_width(struct
>> dwc2_hsotg *hsotg)
>> val = (hsotg->hw_params.utmi_phy_data_width ==
>> GHWCFG4_UTMI_PHY_DATA_WIDTH_8) ? 8 : 16;
>> + if (hsotg->phy) {
>> + /*
>> + * If using the generic PHY framework, check if the PHY bus
>> + * width is 8-bit and set the phyif appropriately.
>> + */
>> + if (phy_get_bus_width(hsotg->phy) == 8)
>> + val = 8;
>> + }
>> +
>> hsotg->params.phy_utmi_width = val;
>> }
>> diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
>> index d10a7f8daec3..e98d7812da2d 100644
>> --- a/drivers/usb/dwc2/platform.c
>> +++ b/drivers/usb/dwc2/platform.c
>> @@ -271,15 +271,6 @@ static int dwc2_lowlevel_hw_init(struct
>> dwc2_hsotg *hsotg)
>> hsotg->plat = dev_get_platdata(hsotg->dev);
>> - if (hsotg->phy) {
>> - /*
>> - * If using the generic PHY framework, check if the PHY bus
>> - * width is 8-bit and set the phyif appropriately.
>> - */
>> - if (phy_get_bus_width(hsotg->phy) == 8)
>> - hsotg->params.phy_utmi_width = 8;
>> - }
>> -
>> /* Clock */
>> hsotg->clk = devm_clk_get_optional(hsotg->dev, "otg");
>> if (IS_ERR(hsotg->clk)) {
>>
>
>
>
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
USB reset problem
Hello All,
Recently we saw a problem where the device reset will fail due to a
configuration descriptor check in hub.c:5600.
if (memcmp(buf, udev->rawdescriptors[index], old_length)
!= 0) {
dev_dbg(&udev->dev, "config index %d changed (#%d)\n",
index,
((struct usb_config_descriptor *) buf)->
bConfigurationValue);
changed = 1;
break;
}
The descriptors returned from the device have a different iInterface. I
checked the usb spec and couldn’t find anything that says iInterface can’t
change. I don’t have the source for the device, but I think it’s probably
generating the interface string each reset and returning a different index for
it (“ADB interface”).
Has anyone else seen this? Does the spec guarantee that iInterface should
never change between device resets?
Thanks,
Seth
Re: Slow I/O on USB media
Il giorno mer, 05/06/2019 alle 19.39 +0200, Greg KH ha scritto: > On Wed, Jun 05, 2019 at 06:23:58PM +0200, Andrea Vai wrote: > [...] > > > Anyway, I know that I can do all of this in a better way, and will > let > > you know. > > Yes, please do so, your steps above do not show much. Here I am with another question. What I have done so far: - booted with the last kernel I know to be working (4.20.13- 200.fc29.x86_64, installed from Fedora repos), checked that test runs fine (2min to copy) - marked "git bisect good v4.20.13" - built the latest stable version: - git clone https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git - cp -v /boot/config-$(uname -r) .config - make -j4 && make modules_install && make install && grub2-mkconfig -o /boot/grub2/grub.cfg - grubby --set-default /boot/vmlinuz-5.2.0-rc3 (the last regular file listed in "ls -lrt /boot/v*") - rebooted with kernel 5.2.0-rc3, ran the test, took 49min to copy (!), thus marked "git bisect bad" - built again, and it turns out to be 4.20.0 (why is it earlier than 4.20.13?), rebooted with 4.20.0, ran the test and it took more than 15 minutes so I killed the cp process, and marked it BAD, and obtained: The merge base 8fe28cb58bcb235034b64cbbb7550a8a43fd88be is bad. This means the bug has been fixed between 8fe28cb58bcb235034b64cbbb7550a8a43fd88be and [0f7c162c1df596e0bba04c26fc9cc497983bf32b]. The output of "git bisect log" is: git bisect start # good: [0f7c162c1df596e0bba04c26fc9cc497983bf32b] Linux 4.20.13 git bisect good 0f7c162c1df596e0bba04c26fc9cc497983bf32b # bad: [f2c7c76c5d0a443053e94adb9f0918fa2fb85c3a] Linux 5.2-rc3 git bisect bad f2c7c76c5d0a443053e94adb9f0918fa2fb85c3a # bad: [8fe28cb58bcb235034b64cbbb7550a8a43fd88be] Linux 4.20 git bisect bad 8fe28cb58bcb235034b64cbbb7550a8a43fd88be I can understand that the bug was present before 4.20.13 (is that reasonable?), but how can I tell bisect to start at 4.20.13, which I know for sure to be working, and not from 4.20.0, which I actually don't care about? I am afraid I am missing something obvious, sorry Thank you very much, Andrea
Re: [PATCH usbutils] usb-devices.1: don't mention bash
On Tue, May 28, 2019 at 02:37:04PM +0300, Baruch Siach wrote:
> Since commit 508d1acf42e ("usb-devices: use /bin/sh hashbang")
> usb-devices does not require bash.
>
> Signed-off-by: Baruch Siach
> ---
> usb-devices.1.in | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/usb-devices.1.in b/usb-devices.1.in
> index c5c1b798e4c3..2b142371cd67 100644
> --- a/usb-devices.1.in
> +++ b/usb-devices.1.in
> @@ -11,7 +11,7 @@ usb-devices \- print USB device details
>
> .SH DESCRIPTION
> .B usb-devices
> -is a (bash) shell script that can be used to display details of USB
> +is a shell script that can be used to display details of USB
> buses in the system and the devices connected to them.
>
> The output of the script is similar to the \fIusb/devices\fP file
> --
> 2.20.1
>
Now applied, thanks!
greg k-h
Re: Slow I/O on USB media
On Thu, 6 Jun 2019, Andrea Vai wrote: > Here I am with another question. > What I have done so far: > > - booted with the last kernel I know to be working (4.20.13- > 200.fc29.x86_64, installed from Fedora repos), checked that test runs > fine (2min to copy) > - marked "git bisect good v4.20.13" > - built the latest stable version: > - git clone > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git > - cp -v /boot/config-$(uname -r) .config > - make -j4 && make modules_install && make install && grub2-mkconfig -o > /boot/grub2/grub.cfg > - grubby --set-default /boot/vmlinuz-5.2.0-rc3 (the last regular file > listed in "ls -lrt /boot/v*") > - rebooted with kernel 5.2.0-rc3, ran the test, took 49min to copy > (!), thus marked "git bisect bad" > - built again, and it turns out to be 4.20.0 (why is it earlier than > 4.20.13?), rebooted with 4.20.0, ran the test and it took more than 15 > minutes so I killed the cp process, and marked it BAD, and obtained: > > The merge base 8fe28cb58bcb235034b64cbbb7550a8a43fd88be is bad. > This means the bug has been fixed between > 8fe28cb58bcb235034b64cbbb7550a8a43fd88be and > [0f7c162c1df596e0bba04c26fc9cc497983bf32b]. > > The output of "git bisect log" is: > > git bisect start > # good: [0f7c162c1df596e0bba04c26fc9cc497983bf32b] Linux 4.20.13 > git bisect good 0f7c162c1df596e0bba04c26fc9cc497983bf32b > # bad: [f2c7c76c5d0a443053e94adb9f0918fa2fb85c3a] Linux 5.2-rc3 > git bisect bad f2c7c76c5d0a443053e94adb9f0918fa2fb85c3a > # bad: [8fe28cb58bcb235034b64cbbb7550a8a43fd88be] Linux 4.20 > git bisect bad 8fe28cb58bcb235034b64cbbb7550a8a43fd88be > > I can understand that the bug was present before 4.20.13 (is that > reasonable?), but how can I tell bisect to start at 4.20.13, which I > know for sure to be working, and not from 4.20.0, which I actually > don't care about? So what you got was a meaningless result. Bisection works by assuming assuming that it's looking for a commit that introduced a problem. If the earliest commit you test already has the problem (and 4.20.0 is earlier than 4.20.13) then bisection won't do anything. In your case it looks like something added between 4.20.0 and 4.20.13 caused the problem to go away! You can still use bisection to find the commit which did that, but the idea is a little unintuitive. Start out by telling git that 4.20.0 is "good" and 4.20.13 is "bad". Then test the intermediate commits as you have been doing, and say that the commit is "good" if the copy takes a long time and "bad" if the copy takes a short time. That should help to find the first commit which caused the problem to go away. (Assuming that the problem is caused by the kernel and not by something else...) Alan Stern
Re: USB reset problem
On Thu, Jun 06, 2019 at 01:55:37PM +, Bollinger, Seth wrote:
> Hello All,
>
> Recently we saw a problem where the device reset will fail due to a
> configuration descriptor check in hub.c:5600.
>
> if (memcmp(buf, udev->rawdescriptors[index], old_length)
> != 0) {
> dev_dbg(&udev->dev, "config index %d changed (#%d)\n",
> index,
> ((struct usb_config_descriptor *) buf)->
> bConfigurationValue);
> changed = 1;
> break;
> }
>
> The descriptors returned from the device have a different iInterface. I
> checked the usb spec and couldn’t find anything that says iInterface can’t
> change. I don’t have the source for the device, but I think it’s probably
> generating the interface string each reset and returning a different index
> for it (“ADB interface”).
>
> Has anyone else seen this? Does the spec guarantee that iInterface should
> never change between device resets?
If the descriptor changes between resets, that means that something
changed and we need to start over with it. What is the problem that
this is causing?
thanks,
greg k-h
Re: USB reset problem
On Thu, 6 Jun 2019, Bollinger, Seth wrote:
> Hello All,
>
> Recently we saw a problem where the device reset will fail due to a
> configuration descriptor check in hub.c:5600.
>
> if (memcmp(buf, udev->rawdescriptors[index], old_length)
> != 0) {
> dev_dbg(&udev->dev, "config index %d changed (#%d)\n",
> index,
> ((struct usb_config_descriptor *) buf)->
> bConfigurationValue);
> changed = 1;
> break;
> }
>
> The descriptors returned from the device have a different iInterface.
> I checked the usb spec and couldn’t find anything that says
> iInterface can’t change. I don’t have the source for the device,
> but I think it’s probably generating the interface string each
> reset and returning a different index for it (“ADB interface”).
>
> Has anyone else seen this? Does the spec guarantee that iInterface
> should never change between device resets?
I have not seen this, and the spec doesn't really guarantee anything
about what happens between device resets.
On the other hand, saying the reset failed in this case is not
unreasonable. The end result is that the device will be re-enumerated
with its new iInterface value.
If this is really a problem we can change the code so that the
iManufacturer, iProduct, iSerialNumber, iConfiguration, and iInterface
descriptor values are exempt from the change check. It would be a
little difficult, though, because we would have to parse the
descriptors to find out where the iInterface values are.
Alan Stern
Re: Slow I/O on USB media
On Thu, Jun 06, 2019 at 04:00:52PM +0200, Andrea Vai wrote: > Il giorno mer, 05/06/2019 alle 19.39 +0200, Greg KH ha scritto: > > On Wed, Jun 05, 2019 at 06:23:58PM +0200, Andrea Vai wrote: > > [...] > > > > > Anyway, I know that I can do all of this in a better way, and will > > let > > > you know. > > > > Yes, please do so, your steps above do not show much. > > Here I am with another question. > What I have done so far: > > - booted with the last kernel I know to be working (4.20.13- > 200.fc29.x86_64, installed from Fedora repos), checked that test runs We have no idea what is in a random distro kernel, sorry. So I would start with a kernel.org kernel. That keeps things at an even level, and you are using a "known good" configuration as well. > fine (2min to copy) > - marked "git bisect good v4.20.13" > - built the latest stable version: > - git clone > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git > - cp -v /boot/config-$(uname -r) .config > - make -j4 && make modules_install && make install && grub2-mkconfig -o > /boot/grub2/grub.cfg > - grubby --set-default /boot/vmlinuz-5.2.0-rc3 (the last regular file > listed in "ls -lrt /boot/v*") > - rebooted with kernel 5.2.0-rc3, ran the test, took 49min to copy > (!), thus marked "git bisect bad" > - built again, and it turns out to be 4.20.0 (why is it earlier than > 4.20.13?), rebooted with 4.20.0, ran the test and it took more than 15 > minutes so I killed the cp process, and marked it BAD, and obtained: > > The merge base 8fe28cb58bcb235034b64cbbb7550a8a43fd88be is bad. > This means the bug has been fixed between > 8fe28cb58bcb235034b64cbbb7550a8a43fd88be and > [0f7c162c1df596e0bba04c26fc9cc497983bf32b]. > > The output of "git bisect log" is: > > git bisect start > # good: [0f7c162c1df596e0bba04c26fc9cc497983bf32b] Linux 4.20.13 > git bisect good 0f7c162c1df596e0bba04c26fc9cc497983bf32b > # bad: [f2c7c76c5d0a443053e94adb9f0918fa2fb85c3a] Linux 5.2-rc3 > git bisect bad f2c7c76c5d0a443053e94adb9f0918fa2fb85c3a > # bad: [8fe28cb58bcb235034b64cbbb7550a8a43fd88be] Linux 4.20 > git bisect bad 8fe28cb58bcb235034b64cbbb7550a8a43fd88be > > I can understand that the bug was present before 4.20.13 (is that > reasonable?), but how can I tell bisect to start at 4.20.13, which I > know for sure to be working, and not from 4.20.0, which I actually > don't care about? > > I am afraid I am missing something obvious, sorry As Alan said, 4.20 is older than 4.20.13. But, is the kernel.org version of 4.20.13 really "good" here? I would start with Linus's tree and stay away from the stable trees for now. As you end up with odd "leafs" that can confuse 'git bisect' and everyone else. So start with 4.20.0. Test that. If it is "good", then great! If not, then maybe you are not really using the same kernel configuration that Fedora is, _or_ Fedora has some odd kernel patch added that makes things an order of magnitude faster :) thanks, greg k-h
Re: USB reset problem
> On Jun 6, 2019, at 9:36 AM, Greg KH wrote: > > If the descriptor changes between resets, that means that something > changed and we need to start over with it. What is the problem that > this is causing We have code doing a USBDEVFS_RESET that fails when the ioctl returns EPERM. I think the solution might be to simply not do the reset for this device, but wanted to check if anyone else had encountered this issue. Thanks! Seth
Re: USB reset problem
> On Jun 6, 2019, at 9:37 AM, Alan Stern > mailto:st...@rowland.harvard.edu>> wrote: > > If this is really a problem we can change the code so that the > iManufacturer, iProduct, iSerialNumber, iConfiguration, and iInterface > descriptor values are exempt from the change check. It would be a > little difficult, though, because we would have to parse the > descriptors to find out where the iInterface values are. It seems like this is a legitimate protection. It wouldn’t feel right to me pushing for a change that would only fix my particular device. If I find we _really_ need it, I can patch our specific kernel. Thanks for the quick responses! Seth
Re: USB reset problem
On Thu, 6 Jun 2019, Bollinger, Seth wrote: > > On Jun 6, 2019, at 9:36 AM, Greg KH wrote: > > > > If the descriptor changes between resets, that means that something > > changed and we need to start over with it. What is the problem that > > this is causing > > We have code doing a USBDEVFS_RESET that fails when the ioctl returns EPERM. EPERM means that the file descriptor was not opened with write access. It has nothing to do with reset failures. > I think the solution might be to simply not do the reset for this device, but > wanted to check if anyone else had encountered this issue. It's true that many programs using usbfs do unnecessary resets. If you don't need it, don't do it! Alan Stern
Re: USB reset problem
> On Jun 6, 2019, at 10:03 AM, Alan Stern wrote: > > EPERM means that the file descriptor was not opened with write access. > It has nothing to do with reset failures. Yes, I was confused by that as well so spent some time instrumenting the kernel. It definitely is open for writing, and get’s by the initial f_mode check in devio.c:usbdev_do_ioctl. Is it possibly a default error that’s returned when some deeper error is encountered? Unfortunately I was unable to determine exactly where it was coming from... Seth
Re: USB reset problem
On Thu, Jun 06, 2019 at 03:19:14PM +, Bollinger, Seth wrote: > > On Jun 6, 2019, at 10:03 AM, Alan Stern wrote: > > > > EPERM means that the file descriptor was not opened with write access. > > It has nothing to do with reset failures. > > Yes, I was confused by that as well so spent some time instrumenting the > kernel. It definitely is open for writing, and get’s by the initial f_mode > check in devio.c:usbdev_do_ioctl. > > Is it possibly a default error that’s returned when some deeper error is > encountered? Unfortunately I was unable to determine exactly where it was > coming from... ftrace is your friend :)
Re: kernel NULL pointer dereference, ucsi bug
Finally I can name the first bad commit:
git bisect good
ad74b8649beaf1a22cf8641324e3321fa0269d16 is the first bad commit
commit ad74b8649beaf1a22cf8641324e3321fa0269d16
Author: Heikki Krogerus
Date: Tue Apr 23 17:21:48 2019 +0300
usb: typec: ucsi: Preliminary support for alternate modes
With UCSI the alternate modes, just like everything else
related to USB Type-C connectors, are handled in firmware.
The operating system can see the status and is allowed to
request certain things, for example entering and exiting the
modes, but the support for alternate modes is very limited
in UCSI. The feature is also optional, which means that even
when the platform supports alternate modes, the operating
system may not be even made aware of them.
UCSI does not support direct VDM reading or writing.
Instead, alternate modes can be entered and exited using a
single custom command which takes also an optional SVID
specific configuration value as parameter. That means every
supported alternate mode has to be handled separately in
UCSI driver.
This commit does not include support for any specific
alternate mode. The discovered alternate modes are now
registered, but binding a driver to an alternate mode will
not be possible until support for that alternate mode is
added to the UCSI driver.
Tested-by: Ajay Gupta
Signed-off-by: Heikki Krogerus
Signed-off-by: Greg Kroah-Hartman
:04 04 f19a610d131d6d3e6397934562dd6112e78b2415
76df0e463eeacf57157adba0291fc9577c7d5145 M dr
ivers
git bisect log
git bisect start
# bad: [132d68d37d33f1d0b9c1f507c8b4d64c27ecec8a] Merge tag
'usb-5.2-rc1' of git://git.kernel.org/pub/scm/
linux/kernel/git/gregkh/usb
git bisect bad 132d68d37d33f1d0b9c1f507c8b4d64c27ecec8a
# good: [86dc59e39031fb0d366d5b1f92db015b24bef70b] net: dsa: sja1105:
Make 'sja1105et_regs' and 'sja1105pq
rs_regs' static
git bisect good 86dc59e39031fb0d366d5b1f92db015b24bef70b
# good: [80f232121b69cc69a31ccb2b38c1665d770b0710] Merge
git://git.kernel.org/pub/scm/linux/kernel/git/dav
em/net-next
git bisect good 80f232121b69cc69a31ccb2b38c1665d770b0710
# good: [5d438e200215f61ca6a7aa69f3c4e035ac54d8ee] usb: typec: ucsi:
ccg: add get_fw_info function
git bisect good 5d438e200215f61ca6a7aa69f3c4e035ac54d8ee
# bad: [6f6a407a591ebe3e4c6bd2329b29862b3980a3ca] Merge tag
'usb-serial-5.2-rc1' of https://git.kernel.org
/pub/scm/linux/kernel/git/johan/usb-serial into usb-next
git bisect bad 6f6a407a591ebe3e4c6bd2329b29862b3980a3ca
# bad: [e823d948b7e53dc982c867ac4ce7877fc0418897] usb: musb: dsps: Use
dev_get_drvdata()
git bisect bad e823d948b7e53dc982c867ac4ce7877fc0418897
# bad: [6fee3787ea7aebf25fecdce325ee9b2150c5727b] dt-bindings:
usb-xhci: Add r8a774c0 support
git bisect bad 6fee3787ea7aebf25fecdce325ee9b2150c5727b
# bad: [cf28369c634fafb5f4e81750cba6988cdb4b4490] usb: typec: Add
driver for NVIDIA Alt Modes
git bisect bad cf28369c634fafb5f4e81750cba6988cdb4b4490
# bad: [ad74b8649beaf1a22cf8641324e3321fa0269d16] usb: typec: ucsi:
Preliminary support for alternate mode
s
git bisect bad ad74b8649beaf1a22cf8641324e3321fa0269d16
# good: [5c9ae5a87573d38cfc4c740aafda2fa6ce06e401] usb: typec: ucsi:
ccg: add firmware flashing support
git bisect good 5c9ae5a87573d38cfc4c740aafda2fa6ce06e401
# first bad commit: [ad74b8649beaf1a22cf8641324e3321fa0269d16] usb:
typec: ucsi: Preliminary support for a
lternate modes
Best regards,
Vladimir
чт, 6 июн. 2019 г. в 02:59, Greg KH :
>
> On Wed, Jun 05, 2019 at 04:36:23PM +1000, Vladimir Yerilov wrote:
> > Good day Mr. Kroah-Hartman,
> >
> > I've found the culprit commit. It took a while though but now I'm sure:
> >
> > commit - brief decription - time - works (y) or not (n)
> > 670784fb4ebe54434e263837390e358405031d9e - rc1 2019-05-20
> > e260ad01f0aa9e96b5386d5cd7184afd949dc457 - rc0 2019-05-14 19:52:51 -0700 n
> > 8ea5b2abd07e2280a332bd9c1a7f4dd15b9b6c13 - rc0 2019-05-09 19:35:41 -0700 n
> > 54516da1ea859dd4f56ebba2e483d2df9d7c8a32 - rc0 2019-05-05 21:58:36 -0700 y
> > 71ae5fc87c34ecbdca293c2a5c563d6be2576558 - rc0 2019-05-06 20:29:45 -0700 y
> > 80f232121b69cc69a31ccb2b38c1665d770b0710 - rc0 2019-05-07 22:03:58 -0700 y
> > a2d635decbfa9c1e4ae15cb05b68b2559f7f827c - rc0 2019-05-08 21:35:19 -0700 n
> > 132d68d37d33f1d0b9c1f507c8b4d64c27ecec8a - rc0 2019-05-08 10:03:52 -0700 n
> > 86dc59e39031fb0d366d5b1f92db015b24bef70b - rc0 2019-05-08 09:46:44 -0700 y
> >
> > So 86dc59e39031fb0d366d5b1f92db015b24bef70b is the last working for
> > me, and 132d68d37d33f1d0b9c1f507c8b4d64c27ecec8a is the breaking one:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.2-rc3&id=132d68d37d33f1d0b9c1f507c8b4d64c27ecec8a
>
> 132d68d37d33 ("Merge tag 'usb-5.2-rc1' of
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb")
> is a merge point, which is odd, you should be able to drop down into
> that and find the exact wrong commit.
>
> what does 'git bisect log' show?
>
> thanks,
>
> greg k-h
--
[GIT PULL] USB: fixes for v5.2-rc4
Hi Greg, Here's my first set of fixes for this -rc cycle. Looks like most of what I have in my inbox these days are new features. Very little fixes. I guess folks are writing perfect code now :-p Let me know if you want anything to be changed. Cheers _ < That's some perfect C, partner. > - \ ^__^ \ (oo)\___ (__)\ )\/\ ||w | || || The following changes since commit f2c7c76c5d0a443053e94adb9f0918fa2fb85c3a: Linux 5.2-rc3 (2019-06-02 13:55:33 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/fixes-for-v5.2-rc4 for you to fetch changes up to 42cc68868ce9d5f5277f561bb17b4746a332bb28: usb: gadget: udc: lpc32xx: fix return value check in lpc32xx_udc_probe() (2019-06-06 13:51:57 +0300) USB: fixes for v5.2-rc4 DWC2 gets a fix for zlp handling which allows DWC2 to pass USBCV MSC tests. A memory leak in fusb300 was plugged. DWC2 also got a fix for wMaxPacketSize handling while acting as host which fixes a regression with USB Cameras. Apart from these, the usual set of minor fixes. Signed-off-by: Felipe Balbi Alexandre Belloni (1): usb: gadget: udc: lpc32xx: allocate descriptor with GFP_ATOMIC Andrey Smirnov (1): usb: phy: mxs: Disable external charger detect in mxs_phy_hw_init() Andrzej Pietrasiewicz (1): usb: gadget: dwc2: fix zlp handling Douglas Anderson (1): usb: dwc2: host: Fix wMaxPacketSize handling (fix webcam regression) Martin Schiller (1): usb: dwc2: Fix DMA cache alignment issues Minas Harutyunyan (1): usb: dwc2: Set actual frame number for completed ISOC transfer for none DDMA Wei Yongjun (1): usb: gadget: udc: lpc32xx: fix return value check in lpc32xx_udc_probe() Young Xiao (1): usb: gadget: fusb300_udc: Fix memory leak of fusb300->ep[i] drivers/usb/dwc2/gadget.c| 24 ++ drivers/usb/dwc2/hcd.c | 39 ++-- drivers/usb/dwc2/hcd.h | 20 +- drivers/usb/dwc2/hcd_intr.c | 5 +++-- drivers/usb/dwc2/hcd_queue.c | 10 + drivers/usb/gadget/udc/fusb300_udc.c | 5 + drivers/usb/gadget/udc/lpc32xx_udc.c | 7 +++ drivers/usb/phy/phy-mxs-usb.c| 14 + 8 files changed, 82 insertions(+), 42 deletions(-) -- balbi signature.asc Description: PGP signature
[PATCH 1/5] usb: xhci: dbc: make DbC modular, introducing dbc_function structure
This patch introduces the dbc_function structure as a first step in
making DbC modular and capable in exposing different user interfaces using
different "functions", which may implement the callbacks exposed here
according to the driver's need.
Only one "function" can be registered at a time.
The generic way to enable a DbC function would be, using sys-fs:
Locate the directory for PCI enumerated XHCI host controller in the
sysfs path.
e.g.: cd /sys/bus/pci/devices/:00:14.0
$ echo "enable" > dbc
This is done AFTER the function is selected at build time. Only 1 function
can be selected at a time.
Signed-off-by: Rajaram Regupathy
Signed-off-by: Abhilash K V
Signed-off-by: Prabhat Chand Pandey
Acked-by: Mathias Nyman
---
drivers/usb/host/xhci-dbgcap.c | 159 ++---
drivers/usb/host/xhci-dbgcap.h | 32 ++-
2 files changed, 138 insertions(+), 53 deletions(-)
diff --git a/drivers/usb/host/xhci-dbgcap.c b/drivers/usb/host/xhci-dbgcap.c
index 52e32644a4b2..96adc53b0fdb 100644
--- a/drivers/usb/host/xhci-dbgcap.c
+++ b/drivers/usb/host/xhci-dbgcap.c
@@ -9,11 +9,14 @@
#include
#include
#include
+#include
#include "xhci.h"
#include "xhci-trace.h"
#include "xhci-dbgcap.h"
+static struct dbc_function *dbc_registered_func;
+
static inline void *
dbc_dma_alloc_coherent(struct xhci_hcd *xhci, size_t size,
dma_addr_t *dma_handle, gfp_t flags)
@@ -35,41 +38,42 @@ dbc_dma_free_coherent(struct xhci_hcd *xhci, size_t size,
size, cpu_addr, dma_handle);
}
-static u32 xhci_dbc_populate_strings(struct dbc_str_descs *strings)
+static u32 xhci_dbc_populate_strings(struct dbc_str_descs *strings,
+ struct dbc_function *func)
{
struct usb_string_descriptor*s_desc;
u32 string_length;
/* Serial string: */
s_desc = (struct usb_string_descriptor *)strings->serial;
- utf8s_to_utf16s(DBC_STRING_SERIAL, strlen(DBC_STRING_SERIAL),
+ utf8s_to_utf16s(func->string.serial, strlen(func->string.serial),
UTF16_LITTLE_ENDIAN, (wchar_t *)s_desc->wData,
DBC_MAX_STRING_LENGTH);
- s_desc->bLength = (strlen(DBC_STRING_SERIAL) + 1) * 2;
+ s_desc->bLength = (strlen(func->string.serial) + 1) * 2;
s_desc->bDescriptorType = USB_DT_STRING;
string_length = s_desc->bLength;
string_length <<= 8;
/* Product string: */
s_desc = (struct usb_string_descriptor *)strings->product;
- utf8s_to_utf16s(DBC_STRING_PRODUCT, strlen(DBC_STRING_PRODUCT),
+ utf8s_to_utf16s(func->string.product, strlen(func->string.product),
UTF16_LITTLE_ENDIAN, (wchar_t *)s_desc->wData,
DBC_MAX_STRING_LENGTH);
- s_desc->bLength = (strlen(DBC_STRING_PRODUCT) + 1) * 2;
+ s_desc->bLength = (strlen(func->string.product) + 1) * 2;
s_desc->bDescriptorType = USB_DT_STRING;
string_length += s_desc->bLength;
string_length <<= 8;
/* Manufacture string: */
s_desc = (struct usb_string_descriptor *)strings->manufacturer;
- utf8s_to_utf16s(DBC_STRING_MANUFACTURER,
- strlen(DBC_STRING_MANUFACTURER),
+ utf8s_to_utf16s(func->string.manufacturer,
+ strlen(func->string.manufacturer),
UTF16_LITTLE_ENDIAN, (wchar_t *)s_desc->wData,
DBC_MAX_STRING_LENGTH);
- s_desc->bLength = (strlen(DBC_STRING_MANUFACTURER) + 1) * 2;
+ s_desc->bLength = (strlen(func->string.manufacturer) + 1) * 2;
s_desc->bDescriptorType = USB_DT_STRING;
string_length += s_desc->bLength;
string_length <<= 8;
@@ -84,7 +88,9 @@ static u32 xhci_dbc_populate_strings(struct dbc_str_descs
*strings)
return string_length;
}
-static void xhci_dbc_init_contexts(struct xhci_hcd *xhci, u32 string_length)
+static void xhci_dbc_init_contexts(struct xhci_hcd *xhci,
+ struct dbc_function *func,
+ u32 string_length)
{
struct xhci_dbc *dbc;
struct dbc_info_context *info;
@@ -124,10 +130,10 @@ static void xhci_dbc_init_contexts(struct xhci_hcd *xhci,
u32 string_length)
/* Set DbC context and info registers: */
xhci_write_64(xhci, dbc->ctx->dma, &dbc->regs->dccp);
- dev_info = cpu_to_le32((DBC_VENDOR_ID << 16) | DBC_PROTOCOL);
+ dev_info = cpu_to_le32((func->vid << 16) | func->protocol);
writel(dev_info, &dbc->regs->devinfo1);
- dev_info = cpu_to_le32((DBC_DEVICE_REV << 16) | DBC_PRODUCT_ID);
+ dev_info = cpu_to_le32((func->device_rev << 16) | func->pid);
writel(dev_info, &dbc->regs->devinfo2);
}
@@ -18
[PATCH 4/5] usb: xhci: dbc: Add a dbc raw driver to provide a raw interface on DbC
From: Abhilash K V
This patch provides a raw device interface on xhci Debug capability.
This abstracts dbc functionality to user space inorder to facilitate
various frameworks to utilize xhci debug capability.
It helps to render the target as an usb debug class device on host and
establish an usb connection by providing two bulk endpoints.
[don't dynamically allocate tiny space for name only -Mathias]
Signed-off-by: Rajaram Regupathy
Signed-off-by: Prabhat Chand Pandey
Signed-off-by: Abhilash K V
Acked-by: Mathias Nyman
---
drivers/usb/host/Kconfig | 9 +
drivers/usb/host/Makefile | 1 +
drivers/usb/host/xhci-dbgraw.c | 365 +
3 files changed, 375 insertions(+)
create mode 100644 drivers/usb/host/xhci-dbgraw.c
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index c29ed8a61dcb..0f801977cd1e 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -48,6 +48,15 @@ config USB_XHCI_DBGCAP_TTY
debug capability. This will expose a /dev/ttyDBC* device node on
device
which may be used by the usb-debug driver on the debug host.
If unsure, say 'N'.
+
+config USB_XHCI_DBGCAP_RAW
+ tristate "xHCI DbC raw driver support"
+ depends on USB_XHCI_HCD && USB_XHCI_DBGCAP
+ help
+ Say 'Y' to enable the support for the raw driver interface to xHCI
+ debug capability. This will expose a device node corresponding to
+ 1 bulk IN and 1 bulk OUT endpoints to be presented to debug host.
+ If unsure, say 'N'.
endchoice
config USB_XHCI_PCI
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index b21b0ea9e966..a4aee6a5daf0 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -20,6 +20,7 @@ ifneq ($(CONFIG_USB_XHCI_DBGCAP), )
endif
obj-$(CONFIG_USB_XHCI_DBGCAP_TTY) += xhci-dbgtty.o
+obj-$(CONFIG_USB_XHCI_DBGCAP_RAW) += xhci-dbgraw.o
ifneq ($(CONFIG_USB_XHCI_MTK), )
xhci-hcd-y += xhci-mtk-sch.o
diff --git a/drivers/usb/host/xhci-dbgraw.c b/drivers/usb/host/xhci-dbgraw.c
new file mode 100644
index ..f7ca4b089dbd
--- /dev/null
+++ b/drivers/usb/host/xhci-dbgraw.c
@@ -0,0 +1,365 @@
+// SPDX-License-Identifier: GPL-2.0+
+/**
+ * Raw DbC for xHCI debug capability
+ *
+ * Copyright (C) 2019 Intel Corporation
+ *
+ * Author: Rajaram Regupathy
+ * Author: Abhilash K V
+ * Author: Prabhat Chand Pandey
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "xhci.h"
+#include "xhci-dbgcap.h"
+
+#define DBC_XHCI_MINORS 8
+#define DBC_STR_FUNC_RAW"RAW"
+#define DBC_RAW_BULK_BUFFER_SIZE (SZ_64K)
+
+static DEFINE_IDR(dbc_minors);
+
+struct dbc_dev {
+ struct mutex dev_excl;
+ struct mutex read_excl;
+ struct mutex write_excl;
+
+ wait_queue_head_t read_wq;
+ wait_queue_head_t write_wq;
+
+ int error;
+ bool in_use;
+ char name[16];
+ struct xhci_dbc *dbc;
+ struct miscdevice misc_dev;
+};
+
+static void xhci_dbc_free_req(struct dbc_ep *dep, struct dbc_request *req)
+{
+ kfree(req->buf);
+ dbc_free_request(dep, req);
+}
+
+struct dbc_request *xhci_dbc_alloc_requests(struct dbc_ep *dep,
+ void (*fn)(struct xhci_hcd *, struct dbc_request *))
+{
+ struct dbc_request *req;
+
+ req = dbc_alloc_request(dep, GFP_KERNEL);
+ if (!req)
+ return req;
+
+ req->length = DBC_RAW_BULK_BUFFER_SIZE;
+ req->buf = kmalloc(req->length, GFP_KERNEL);
+ if (!req->buf)
+ xhci_dbc_free_req(dep, req);
+
+ req->complete = fn;
+
+ return req;
+}
+
+static void dbc_complete_in(struct xhci_hcd *xhci,
+ struct dbc_request *req)
+{
+ struct xhci_dbc *dbc = (struct xhci_dbc *) xhci->dbc;
+ struct dbc_dev *dev = (struct dbc_dev *) dbc->func_priv;
+
+ if (req->status)
+ dev->error = req->status;
+
+ wake_up(&dev->write_wq);
+}
+
+static void dbc_complete_out(struct xhci_hcd *xhci,
+ struct dbc_request *req)
+{
+ struct xhci_dbc *dbc = (struct xhci_dbc *) xhci->dbc;
+ struct dbc_dev *dev = (struct dbc_dev *) dbc->func_priv;
+
+ if (req->status)
+ dev->error = req->status;
+
+ wake_up(&dev->read_wq);
+}
+
+static ssize_t dbc_read(struct file *fp, char __user *buf,
+ size_t count, loff_t *pos)
+{
+ int status = 0;
+ struct dbc_dev *dev = (struct dbc_dev *) fp->private_data;
+ struct xhci_dbc *dbc = dev->dbc;
+ struct dbc_request *req;
+ struct dbc_port *port = &dbc->port;
+ int r = count, xfer;
+ int ret;
+
+ if (dbc->state != DS_CONFIGURED)
+ return -EAGAIN;
+
+ port->in = get_in_ep(dbc->xhci);
+
+ mutex_lock(&dev->read_excl);
+
+ req = xhci_dbc_alloc_requests(port->in, dbc_complete_out);
+ if (!req) {
+
[PATCH 0/5] usb: xhci: dbc: make modular and add RAW interface
This patch-set adds the following features to dbc driver: - show the active dbc function and dbc descriptors, allowing user space to dynamically modify the descriptors. - modularize dbc core to enable it to expose different function interfaces, till now only TTY interface was exposed. - use the new framework to expose RAW interface that can be used by any user-space application to directly read from and write into dbc bulk end-points. Abhilash K V (1): usb: xhci: dbc: Add a dbc raw driver to provide a raw interface on DbC K V, Abhilash (1): usb: xhci: dbc: Provide sysfs option to configure dbc descriptors Prabhat Chand Pandey (3): usb: xhci: dbc: make DbC modular, introducing dbc_function structure usb: xhci: dbc: DbC TTY driver to use new interface usb: xhci: dbc: Document describe about dbc raw interface .../testing/sysfs-bus-pci-drivers-xhci_hcd| 112 Documentation/usb/dbc_raw.rst | 136 + Documentation/usb/index.rst | 16 + drivers/usb/host/Kconfig | 24 +- drivers/usb/host/Makefile | 5 +- drivers/usb/host/xhci-dbgcap.c| 498 -- drivers/usb/host/xhci-dbgcap.h| 36 +- drivers/usb/host/xhci-dbgraw.c| 365 + drivers/usb/host/xhci-dbgtty.c| 81 ++- 9 files changed, 1206 insertions(+), 67 deletions(-) create mode 100644 Documentation/usb/dbc_raw.rst create mode 100644 Documentation/usb/index.rst create mode 100644 drivers/usb/host/xhci-dbgraw.c -- 2.21.0
[PATCH 2/5] usb: xhci: dbc: DbC TTY driver to use new interface
Change DbC TTY driver to use the new modular interface exposed by the DbC
core. This will allow other function drivers with a different interface
also to use DbC.
[no need to add running number to tty driver name, remove it. -Mathias]
Signed-off-by: Rajaram Regupathy
Signed-off-by: Abhilash K V
Signed-off-by: Prabhat Chand Pandey
Acked-by: Mathias Nyman
---
drivers/usb/host/Kconfig | 15 ++-
drivers/usb/host/Makefile | 4 +-
drivers/usb/host/xhci-dbgcap.h | 4 --
drivers/usb/host/xhci-dbgtty.c | 81 ++
4 files changed, 90 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index d809671c5fea..c29ed8a61dcb 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -30,13 +30,26 @@ config USB_XHCI_HCD
if USB_XHCI_HCD
config USB_XHCI_DBGCAP
bool "xHCI support for debug capability"
- depends on TTY
---help---
Say 'Y' to enable the support for the xHCI debug capability. Make
sure that your xHCI host supports the extended debug capability and
you want a TTY serial device based on the xHCI debug capability
before enabling this option. If unsure, say 'N'.
+choice
+ prompt "Select function for debug capability"
+ depends on USB_XHCI_DBGCAP
+
+config USB_XHCI_DBGCAP_TTY
+ tristate "xHCI DbC tty driver support"
+ depends on USB_XHCI_HCD && USB_XHCI_DBGCAP && TTY
+ help
+ Say 'Y' to enable the support for the tty driver interface to xHCI
+ debug capability. This will expose a /dev/ttyDBC* device node on
device
+ which may be used by the usb-debug driver on the debug host.
+ If unsure, say 'N'.
+endchoice
+
config USB_XHCI_PCI
tristate
depends on USB_PCI
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 84514f71ae44..b21b0ea9e966 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -16,9 +16,11 @@ xhci-hcd-y += xhci-ring.o xhci-hub.o xhci-dbg.o
xhci-hcd-y += xhci-trace.o
ifneq ($(CONFIG_USB_XHCI_DBGCAP), )
- xhci-hcd-y += xhci-dbgcap.o xhci-dbgtty.o
+ xhci-hcd-y += xhci-dbgcap.o
endif
+obj-$(CONFIG_USB_XHCI_DBGCAP_TTY) += xhci-dbgtty.o
+
ifneq ($(CONFIG_USB_XHCI_MTK), )
xhci-hcd-y += xhci-mtk-sch.o
endif
diff --git a/drivers/usb/host/xhci-dbgcap.h b/drivers/usb/host/xhci-dbgcap.h
index b4d5622a9030..302e6ca72370 100644
--- a/drivers/usb/host/xhci-dbgcap.h
+++ b/drivers/usb/host/xhci-dbgcap.h
@@ -218,10 +218,6 @@ static inline struct dbc_ep *get_out_ep(struct xhci_hcd
*xhci)
#ifdef CONFIG_USB_XHCI_DBGCAP
int xhci_dbc_init(struct xhci_hcd *xhci);
void xhci_dbc_exit(struct xhci_hcd *xhci);
-int xhci_dbc_tty_register_driver(struct xhci_hcd *xhci);
-void xhci_dbc_tty_unregister_driver(void);
-int xhci_dbc_tty_register_device(struct xhci_hcd *xhci);
-void xhci_dbc_tty_unregister_device(struct xhci_hcd *xhci);
struct dbc_request *dbc_alloc_request(struct dbc_ep *dep, gfp_t gfp_flags);
void xhci_dbc_flush_reqests(struct xhci_dbc *dbc);
void dbc_free_request(struct dbc_ep *dep, struct dbc_request *req);
diff --git a/drivers/usb/host/xhci-dbgtty.c b/drivers/usb/host/xhci-dbgtty.c
index aff79ff5aba4..f75a95006c51 100644
--- a/drivers/usb/host/xhci-dbgtty.c
+++ b/drivers/usb/host/xhci-dbgtty.c
@@ -7,13 +7,15 @@
* Author: Lu Baolu
*/
+#include
#include
#include
#include
-
#include "xhci.h"
#include "xhci-dbgcap.h"
+#define DBC_STR_FUNC_TTY"TTY"
+
static unsigned int
dbc_send_packet(struct dbc_port *port, char *packet, unsigned int size)
{
@@ -279,12 +281,11 @@ static const struct tty_operations dbc_tty_ops = {
.unthrottle = dbc_tty_unthrottle,
};
-static struct tty_driver *dbc_tty_driver;
-
-int xhci_dbc_tty_register_driver(struct xhci_hcd *xhci)
+static int xhci_dbc_tty_register_driver(struct xhci_hcd *xhci)
{
int status;
struct xhci_dbc *dbc = xhci->dbc;
+ struct tty_driver *dbc_tty_driver;
dbc_tty_driver = tty_alloc_driver(1, TTY_DRIVER_REAL_RAW |
TTY_DRIVER_DYNAMIC_DEV);
@@ -296,7 +297,6 @@ int xhci_dbc_tty_register_driver(struct xhci_hcd *xhci)
dbc_tty_driver->driver_name = "dbc_serial";
dbc_tty_driver->name = "ttyDBC";
-
dbc_tty_driver->type = TTY_DRIVER_TYPE_SERIAL;
dbc_tty_driver->subtype = SERIAL_TYPE_NORMAL;
dbc_tty_driver->init_termios = tty_std_termios;
@@ -315,16 +315,19 @@ int xhci_dbc_tty_register_driver(struct xhci_hcd *xhci)
put_tty_driver(dbc_tty_driver);
dbc_tty_driver = NULL;
}
+ dbc->func_priv = dbc_tty_driver;
return status;
}
-void xhci_dbc_tty_unregister_driver(void)
+static void xhci_dbc_tty_unregister_driver(struct xhci_dbc *dbc)
{
+ struct tty_driver *dbc_tty_driver =
+
[PATCH 3/5] usb: xhci: dbc: Provide sysfs option to configure dbc descriptors
From: "K V, Abhilash" Show the active dbc function and dbc descriptors, allowing user space to dynamically modify the descriptors The DBC specific sysfs attributes are separated into two groups, in the first group there are dbc & dbc_function sysfs attributes and in second group all other DBC descriptor specific sysfs attributes. First group of attributes will be populated at the time of dbc_init and second group of attributes will only be populated when "dbc" attribute value is set to "enable". Whenever "dbc" attribute value will be "disable" then second group of attributes will be removed. Signed-off-by: Rajaram Regupathy Signed-off-by: Gururaj K Signed-off-by: K V, Abhilash Signed-off-by: Prabhat Chand Pandey Acked-by: Mathias Nyman --- .../testing/sysfs-bus-pci-drivers-xhci_hcd| 112 ++ drivers/usb/host/xhci-dbgcap.c| 339 ++ 2 files changed, 451 insertions(+) diff --git a/Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd b/Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd index 0088aba4caa8..b46b6afc6c4a 100644 --- a/Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd +++ b/Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd @@ -23,3 +23,115 @@ Description: Reading this attribute gives the state of the DbC. It can be one of the following states: disabled, enabled, initialized, connected, configured and stalled. + +What: /sys/bus/pci/drivers/xhci_hcd/.../dbc_function +Date: June 2018 +Contact: Rajaram Regupathy +Description: + xHCI USB host controllers provide Debug Capability (Dbc) + as an extended feature. When configured Dbc presents a + debug device which is fully compliant with the USB + framework. + + This framework can be utilized to provide various interfaces. + By Default, it is configured to provide a serial Interface. + + This attribute lets us configure the interface provided + by Dbc functionality. By Default, this attribute value + is "TTY" corresponding to the the serial interface. Other + values can be supported in future to provide a varied + interface to use DbC. + + Reading this attribute gives the interface which is + currently configured with DbC. If it is "TTY" then serial + interface is configured. + +What: /sys/bus/pci/drivers/xhci_hcd/.../dbc_manufacturer +Date: June 2018 +Contact: Rajaram Regupathy +Description: + xHCI USB host controllers provide Debug Capability (Dbc) + as an extended feature. When configured Dbc presents a + debug device which is fully compliant with the USB + framework. + This attribute lets us change the manufacturer name as + presented by the debug device in the USB Manufacturer String + descriptor. The default value is "Linux Foundation". + +What: /sys/bus/pci/drivers/xhci_hcd/.../dbc_product +Date: June 2018 +Contact: Rajaram Regupathy +Description: + xHCI USB host controllers provide Debug Capability (Dbc) + as an extended feature. When configured Dbc presents a + debug device which is fully compliant with the USB + framework. + This attribute lets us change the product name as + presented by the debug device in the USB Product String + descriptor. The default value is "Linux USB Debug Target". + +What: /sys/bus/pci/drivers/xhci_hcd/.../dbc_serial +Date: June 2018 +Contact: Rajaram Regupathy +Description: + xHCI USB host controllers provide Debug Capability (Dbc) + as an extended feature. When configured Dbc presents a + debug device which is fully compliant with the USB + framework. + This attribute lets us change the serial number as + presented by the debug device in the USB Serial Number String + descriptor. The default value is "0001". + +What: /sys/bus/pci/drivers/xhci_hcd/.../dbc_protocol +Date: June 2018 +Contact: Rajaram Regupathy +Description: + xHCI USB host controllers provide Debug Capability (Dbc) + as an extended feature. When configured Dbc presents a + debug device which is fully compliant with the USB + framework. + This attribute lets us change the bInterfaceProtocol field as + presented by the debug device in the USB Interface descriptor. + + The default value is 1 (GNU Remote Debug command). + Other permissible value is 0 which is for vendor defined debug + target. + +What:
[PATCH 5/5] usb: xhci: dbc: Document describe about dbc raw interface
This patch have explaination about the new DBC interface called dbc raw interface. This cover the capability, target setup and use case info. Signed-off-by: Prabhat Chand Pandey --- Documentation/usb/dbc_raw.rst | 136 ++ Documentation/usb/index.rst | 16 2 files changed, 152 insertions(+) create mode 100644 Documentation/usb/dbc_raw.rst create mode 100644 Documentation/usb/index.rst diff --git a/Documentation/usb/dbc_raw.rst b/Documentation/usb/dbc_raw.rst new file mode 100644 index ..b7d472a478f5 --- /dev/null +++ b/Documentation/usb/dbc_raw.rst @@ -0,0 +1,136 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +== +This described about DBC RAW Interface +== + +:Author: Prabhat Chand Pandey + +Content + + +- DBC Overview +- Motivation +- DBC RAW Capabilities +- Target Build Setup +- Target Test Setup +- Host Target Connection +- Experiment Test Result +- DBC TTY Use Cases +- DBC RAW Use Cases +- Conclusion + +DBC Overview +- +xDBC stands for the USB Debug capability provided extensible Host Controller +Interface. Universal Serial Bus is a host controlled Bus. Host Controller is +a hardware whose functionality is to manage usb bus and usb host ports. It is +responsible for initiating and managing all usb transfers. Extensible Host +Controller Interface (xHCI) is a register-level interface which provides a +mechanism by which the host controller (xHC) can communicate with the Operating +System of the host computer. In addition to exposing register interfaces +essential for proper functioning of the xHC it also supports many extended +capabilities which can optionally be implemented by xHC. + +It includes Extended Power Management Capability, I/O Virtualization capability +USB Legacy support capability among many others. USB Debug Capability is one of +the main extended capabilities supported by xHCI. + +This functionality enables low-level system debug over USB. The xHCI debug +capabilities (xDBC) provides a means of connecting two systems where the system +is a Debug Host and the other is a Debug target. This is achieved through +emulating a debug device by using xDBC on the debug target. The debug device +presented by the debug target can be used by debug host for low level system +debugging of target. + +Motivation +--- +In this patch-set we learn the requirement of new DBC interface called DBC RAW, +which can be used for platform debugging, large data transfer with comparatively +10x faster data rate than DBC TTY and it have all the USB specific error handling +mechanism enabled which DBC TTY doesn't have. + +DBC RAW Capabilities +- +* Current transfer rate of up to 25.4 MB/s from host to target (using Blocking APIs). +* Current transfer rate of up to 28.8 MB/s from target to host (using Blocking APIs). +* Have further scope of improvement in transfer rate of up to USB 3.x speed. +* This interface can bind with multiple target xHCI (i.e. /dev/dbc_raw0, raw1 etc). +* It helps to render the target as an usb debug class device on host and establish + an usb connection by providing two bulk endpoints. +* It has support to handle halt bit and send STALL packet. + +Target Build Setup +--- +* Make sure to use Kernel of version >= 4.13. +* Enable USB_XHCI_DBGCAP in Kernel menuconfig. + Device Drivers ---> USB support ---> xHCI support for debug capability [Y] +* Enable DBC RAW in kernel menuconfig. + Device Drivers ---> USB support ---> Select function for debug capability + (xHCI DbC raw driver support) +* Build Image. + +Target Test Setup +-- +* Flash binary with above changes in the target board. +* Cross check the current DBC function interface, it should be RAW in this case + otherwise TTY, below is the sysfs entry for the dbc_function (it's a read only file, + switching b/w RAW and TTY is only possible at build time): + root@target:/ # cat /sys/bus/pci/devices/\:00\:14.0/dbc_function + RWA +* Enable DBC with the following command: + root@target:/ # echo enable > /sys/bus/pci/devices/\:00\:14.0/dbc + +Host Target Connection +--- +* Connect Type A to Type A cable between Target and Host. +* Make sure it is an usb 3.0 cable. +* At this point debug device should be enumerated on Host side. +* On Target side dbc sysfs attribute should change to configured state and + dbc_raw0 character device should appear under dev directory. + + On Target-: + root@target:/ # cat /sys/bus/pci/devices/\:00\:14.0/dbc + configured + + Target dmesg-: + [ 32.420018] xhci_hcd :00:14.0: DbC connected + [ 32.676014] xhci_hcd :00:14.0: DbC configured + + Host dmesg-: + [3613626.064257] usb 2-1: new SuperSp
