Re: [PATCH] ARM: dts: ls2080a: Add quirk for Erratum A009116
On Tue, Feb 09, 2016 at 05:08:07PM -0600, Lijun Pan wrote:
> Add "snps,quirk-frame-length-adjustment" property to
> USB3 node for erratum A009116. This property provides
> value of GFLADJ_30MHZ for post silicon frame length
> adjustment.
>
> Signed-off-by: Lijun Pan
> ---
> arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi |2 ++
> 1 file changed, 2 insertions(+)
Forgot to mention that arm64 patches use a different subject prefix from
ARM ones. I changed the patch subject to "arm64: dts: ..." when
applying.
Shawn
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> index 6e9e033..fa506f5 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> @@ -501,6 +501,7 @@
> reg = <0x0 0x310 0x0 0x1>;
> interrupts = <0 80 0x4>; /* Level high type */
> dr_mode = "host";
> + snps,quirk-frame-length-adjustment = <0x20>;
> };
>
> usb1: usb3@311 {
> @@ -509,6 +510,7 @@
> reg = <0x0 0x311 0x0 0x1>;
> interrupts = <0 81 0x4>; /* Level high type */
> dr_mode = "host";
> + snps,quirk-frame-length-adjustment = <0x20>;
> };
>
> ccn@400 {
> --
> 1.7.9.5
>
>
--
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 fixes for 4.5-rc4
The following changes since commit 36f90b0a2ddd60823fe193a85e60ff1906c2a9b3: Linux 4.5-rc2 (2016-01-31 18:12:16 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-4.5-rc4 for you to fetch changes up to 6b44d1e9bf3b850b433694d654709b4cbc9bc00e: Merge tag 'phy-for-4.5-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy into usb-linus (2016-02-11 20:10:58 -0800) USB and PHY fixes for 4.5-rc4 Here are a number of USB and PHY driver fixes for 4.5-rc4. They are the usual gadget and xhci drivers that had reported problems, as well as a few small phy issues as well. All have been in linux-next with no reported issues. Signed-off-by: Greg Kroah-Hartman Chunfeng Yun (2): usb: xhci-mtk: fix bpkts value of LS/HS periodic eps not behind TT usb: xhci-mtk: fix AHB bus hang up caused by roothubs polling Felipe Balbi (1): MAINTAINERS: fix my email address Geert Uytterhoeven (1): phy: Restrict phy-hi6220-usb to HiSilicon arm64 Greg Kroah-Hartman (2): Merge tag 'fixes-for-v4.5-rc3' of git://git.kernel.org/.../balbi/usb into usb-linus Merge tag 'phy-for-4.5-rc' of git://git.kernel.org/.../kishon/linux-phy into usb-linus Gregory CLEMENT (1): usb: host: xhci-plat: fix NULL pointer in probe for device tree case Jianqiang Tang (1): usb: dwc3: gadget: set the OTG flag in dwc3 gadget driver. Joe Lawrence (1): xhci: harden xhci_find_next_ext_cap against device removal John Youn (2): Revert "usb: dwc2: Move reset into dwc2_get_hwparams()" usb: dwc2: Fix probe problem on bcm2835 Li Jun (1): usb: phy: mxs: declare variable with initialized value Lu Baolu (4): usb: xhci: handle both SSIC ports in PME stuck quirk usb: xhci: add a quirk bit for ssic port unused usb: xhci: set SSIC port unused only if xhci_suspend succeeds usb: xhci: apply XHCI_PME_STUCK_QUIRK to Intel Broxton-M platforms Mathias Nyman (2): Revert "xhci: don't finish a TD if we get a short-transfer event mid TD" xhci: Fix list corruption in urb dequeue at host removal Shawn Lin (1): phy: core: fix wrong err handle for phy_power_on Srinivas Kandagatla (1): usb: phy: msm: fix error handling in probe. Tony Lindgren (2): phy: twl4030-usb: Relase usb phy on unload phy: twl4030-usb: Fix unbalanced pm_runtime_enable on module reload Ulf Hansson (1): usb: musb: ux500: Fix NULL pointer dereference at system PM MAINTAINERS | 10 +++ drivers/phy/Kconfig | 1 + drivers/phy/phy-core.c | 16 +++- drivers/phy/phy-twl4030-usb.c| 14 ++ drivers/usb/dwc2/core.c | 14 -- drivers/usb/dwc2/platform.c | 8 +- drivers/usb/dwc3/gadget.c| 1 + drivers/usb/host/xhci-ext-caps.h | 4 +++ drivers/usb/host/xhci-mtk-sch.c | 16 +--- drivers/usb/host/xhci-mtk.c | 23 + drivers/usb/host/xhci-pci.c | 56 ++-- drivers/usb/host/xhci-plat.c | 3 ++- drivers/usb/host/xhci-ring.c | 10 --- drivers/usb/host/xhci.c | 4 ++- drivers/usb/host/xhci.h | 1 + drivers/usb/musb/ux500.c | 7 +++-- drivers/usb/phy/phy-msm-usb.c| 37 -- drivers/usb/phy/phy-mxs-usb.c| 2 +- 18 files changed, 150 insertions(+), 77 deletions(-) -- 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: [GIT PULL] USB driver fixes for 4.5-rc4
On Sun, Feb 14, 2016 at 11:01 AM, Greg KH wrote: > > USB and PHY fixes for 4.5-rc4 > > Here are a number of USB and PHY driver fixes for 4.5-rc4. Actually, only PHY fixes. The USB fixes you already sent me for rc3. See merge commit 46df55ceeaf3. Apparently you haven't updated your upstream tree.. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] USB driver fixes for 4.5-rc4
On Sun, Feb 14, 2016 at 12:24:11PM -0800, Linus Torvalds wrote: > On Sun, Feb 14, 2016 at 11:01 AM, Greg KH wrote: > > > > USB and PHY fixes for 4.5-rc4 > > > > Here are a number of USB and PHY driver fixes for 4.5-rc4. > > Actually, only PHY fixes. The USB fixes you already sent me for rc3. > See merge commit 46df55ceeaf3. > > Apparently you haven't updated your upstream tree.. Ugh, you are right, sorry about that, do you need an updated pull request, or are you ok with this one? 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: [GIT PULL] USB driver fixes for 4.5-rc4
On Sun, Feb 14, 2016 at 12:39 PM, Greg KH wrote: > > Ugh, you are right, sorry about that, do you need an updated pull > request, or are you ok with this one? I took it and updates the merge log appropriately. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: FAILED: patch "[PATCH] USB: fix invalid memory access in hub_activate()" failed to apply to 3.10-stable tree
On Wed, Jan 27, 2016 at 02:14:54PM -0500, Alan Stern wrote: > On Mon, 25 Jan 2016 gre...@linuxfoundation.org wrote: > > > The patch below does not apply to the 3.10-stable tree. > > If someone wants it applied there, or to any other stable or longterm > > tree, then please email the backport, including the original git commit > > id to . > > > > thanks, > > > > greg k-h > > > > -- original commit in Linus's tree -- > > > > From e50293ef9775c5f1cf3fcc093037dd6a8c5684ea Mon Sep 17 00:00:00 2001 > > From: Alan Stern > > Date: Wed, 16 Dec 2015 13:32:38 -0500 > > Subject: [PATCH] USB: fix invalid memory access in hub_activate() > > Here is the back-ported patch. This may be needed for other longterm > trees as well. It breaks the build on 3.10 and 3.14 :( drivers/usb/core/hub.c: In function ‘hub_activate’: drivers/usb/core/hub.c:1033:25: error: ‘hub_release’ undeclared (first use in this function) kref_put(&hub->kref, hub_release); ^ So I can't apply it... -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH BACKPORT] xhci:_don't_finish_a_TD_if_we_get_a_short_transfer_event_mid_TD
On Wed, Dec 16, 2015 at 06:22:30AM -0800, Steve Bangert wrote: > Hi, > > This original patch was posted and applied to the 4.3-rcX kernel and tagged > for > stable kernels. > > http://marc.info/?l=linux-usb&m=144463835322214&w=2 > > > But didn't to make it into the 4.1 and 3.14 kernels as it failed > to apply in it's original form. > > A backport from Ben Hutchings was posted during the 3.2.73-rc1 review cycle > and will now apply. > > Please consider for the next stable kernel release cycle. Patch is corrupted and does not apply properly :( -- 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 20/21] usb: support building without CONFIG_HAS_DMA
On Wed, Feb 10, 2016 at 03:29:55PM +0100, Vegard Nossum wrote: > Some platforms don't have DMA, but we should still be able to build > USB drivers for these platforms. They could still be used through > vhci_hcd, usbip_host, or maybe something like USB passthrough in UML > from a capable host. > > This is admittedly ugly with all the #ifdefs, but it is necessary to > get around linker errors like these: Sorry, you are going to have to do something else here, I can't accept this patch, it's just too ugly to read :( -- 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 v7 0/3] usbip: exporting devices
On Wed, Feb 10, 2016 at 10:45:00AM +0900, Nobuo Iwata wrote: > Dear all, > > This series of patches introduces exporting devices. I have no idea what you mean by "exporting devices" :( -- 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 v7 1/3] usbip: exporting devices
On Wed, Feb 10, 2016 at 10:45:01AM +0900, Nobuo Iwata wrote: > USB/IP supports a function to import USB devices from application-side > machine by attach command. > The usage is as following. > dev:# (Physically attach your USB device.) > dev:# insmod usbip-core.ko and usbip-host.ko > dev:# usbipd -D > // Start usbip daemon. > dev:# usbip list -l > // List local USB devices and their busid. > dev:# usbip bind --busid > // Make a device exportable to other hosts. > > app:# insmod usbip-core.ko and vhci-hcd.ko > app:# usbip list --remote > // List importable USB devices from the . > app:# usbip attach --remote --busid > // Import a device > > By attach command, connection will be established from application-side > to device-side. > > This patch introduces a function to export devices form device-side > machine to application-side machine. > The usage is as following. > app:# insmod usbip-core.ko and vhci-hcd.ko > app:# usbipa -D > // Start usbip daemon. > > dev:# (Physically attach your USB device.) > dev:# insmod usbip-core.ko and usbip-host.ko > dev:# usbip list -l > // List local USB devices and their busid. > dev:# usbip connect --remote --busid > // Export a device to . > > For this, export function, connection is established from device-side > machine to application-side machine. > I don't see any benifit here at all, please explain it better. You are saying what your patch does, but not why we would want it. and it is huge: > Following use cases are supposed for the export function. > 1) Server application or cloud service serves distributed ubiquitous > devices. > 2) Dedicate devices to server application or cloud service. > > To connect to cloud service, it needs to connect from inside of > firewall. > > Probably, the export function was planned because the packets were > originally defined in header file usbip_network.h but they were not > used yet. > This patch fixes the defined packet structures (ie. int in reply to > uinit32_t) and use them. > Also, vendor/product name converion is added to port commnad as same as > list command. > > Signed-off-by: Nobuo Iwata > --- > tools/usb/usbip/libsrc/names.c | 2 + > tools/usb/usbip/libsrc/usbip_host_driver.c | 15 ++ > tools/usb/usbip/libsrc/usbip_host_driver.h | 1 + > tools/usb/usbip/libsrc/vhci_driver.c | 127 +-- > tools/usb/usbip/libsrc/vhci_driver.h | 8 +- > tools/usb/usbip/src/Makefile.am| 9 +- > tools/usb/usbip/src/usbip.c| 17 +- > tools/usb/usbip/src/usbip.h| 11 +- > tools/usb/usbip/src/usbip_attach.c | 49 +--- > tools/usb/usbip/src/usbip_bind.c | 7 +- > tools/usb/usbip/src/usbip_connect.c| 214 ++ > tools/usb/usbip/src/usbip_detach.c | 13 +- > tools/usb/usbip/src/usbip_disconnect.c | 202 + > tools/usb/usbip/src/usbip_list.c | 22 +- > tools/usb/usbip/src/usbip_network.h| 5 +- > tools/usb/usbip/src/usbip_port.c | 21 +- > tools/usb/usbip/src/usbip_unbind.c | 7 +- > tools/usb/usbip/src/usbipd.c | 227 ++- > tools/usb/usbip/src/usbipd.h | 36 +++ > tools/usb/usbip/src/usbipd_app.c | 239 > tools/usb/usbip/src/usbipd_dev.c | 247 + > 21 files changed, 1176 insertions(+), 303 deletions(-) That's too much code to review, especially for something that I have no idea what it is, or why it is needed at all. Please be more descriptive here, and hopefully, break this patch down into smaller steps. 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: [PATCH v7 2/3] usbip: readme and manuals about exporting devices
On Wed, Feb 10, 2016 at 10:45:02AM +0900, Nobuo Iwata wrote: > This patch adds function and usage of export to README and manuals. > > The wording, 'server' and 'client' are changed. That sounds like a mistake, why would you do that? You just reversed everything? Why? > For existing attach command, the daemon runs device side machine and > attach command is executed in application side machine. Then 'server' > is used for device side and 'client' is for application side. > > For the new connect command, the daemon runs applications side machine > and connect command is executed in device side machine. Now, 'server' > and 'client' run in different machine than before. So you just broke everything that was working before? That's not acceptable :( 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: [PATCH v3 0/2] usbip: vhci number of ports extension
On Wed, Feb 10, 2016 at 10:55:11AM +0900, Nobuo Iwata wrote: > This series of patches extends number of ports limitaion in application > (vhci) side. What limitation? Why change it? What's the problem here... -- 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 v7 3/3] usbip: safe completion against usb_kill_urb()
On Wed, Feb 10, 2016 at 10:45:03AM +0900, Nobuo Iwata wrote:
> stub_shutdown_connection() : drivers/usb/usbip/stub_dev.c
> stub_device_cleanup_urbs() : drivers/usb/usbip/stub_main.c
> requests to kill pending URBs and clears priv lists.
>
> stub_complete() : drivers/usb/usbip/stub_tx.c might be called with URBs
> to have been requested to kill.
>
> To avoid kernel panic, this patch ignores killed URBs linked to cleared
> priv lists.
> To know the killed URBs in stub_complete(), sdev->ud.tcp_socket which
> cleared before stub_device_cleanup_urbs() is checked.
>
> The critial condition will happen by unbind command before detach,
> broken connection in connect command and disconnect command.
>
> Signed-off-by: Nobuo Iwata
> ---
> drivers/usb/usbip/stub_tx.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/usbip/stub_tx.c b/drivers/usb/usbip/stub_tx.c
> index dbcabc9..f19f321 100644
> --- a/drivers/usb/usbip/stub_tx.c
> +++ b/drivers/usb/usbip/stub_tx.c
> @@ -97,7 +97,9 @@ void stub_complete(struct urb *urb)
>
> /* link a urb to the queue of tx. */
> spin_lock_irqsave(&sdev->priv_lock, flags);
> - if (priv->unlinking) {
> + if (sdev->ud.tcp_socket == NULL) {
> + dev_info(&urb->dev->dev, "discard a urb for closed connection");
> + } else if (priv->unlinking) {
> stub_enqueue_ret_unlink(sdev, priv->seqnum, urb->status);
> stub_free_priv_and_urb(priv);
> } else {
Why this one tiny bugfix at the end of this series? Is this something
that could be applied without the huge 1/3 patch here? If so, please
send it on its own. If not, then please fix it in the place where you
made this bug happen.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/2] usbip: vhci number of ports extension
On Wed, Feb 10, 2016 at 10:55:12AM +0900, Nobuo Iwata wrote: > This patch extends number of ports limitation in application (vhci) > side. > > To do so, vhci driver supports multiple host controllers. The number of > controllers can be specified as a module parameter 'num_controllers'. > The default is 1. > > ex) # insmod vhci_hcd.ko num_controllers=4 I hate module parameters, please don't do that, create these dynamically as needed some other way. > Also, ports per controller is changed from 8 to USB_MAXCHILDREN (31). Why? All in one patch? Not good. > It can be modified with VHCI_NPORTS flag at module compilation. No one does that, make this dynamic as well please, in a series of patches, not just one huge one. 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: [PATCH] usb: storage: make US_DEBUGPX print with LOGLEVEL_DEBUG
On Wed, Feb 10, 2016 at 04:13:43PM -0800, Victor Dodon wrote: > The US_DEBUGPX macro uses printk without specifying a kernel log level, so > the default kernel log level is used, which may not match LOGLEVEL_DEBUG > used in usb_stor_dbg. Use printk_emit with LOGLEVEL_DEBUG instead. > > Signed-off-by: Victor Dodon > --- > drivers/usb/storage/debug.h | 10 -- > 1 file changed, 8 insertions(+), 2 deletions(-) Can you just get rid of US_DEBUGPX() entirely please? It shouldn't be needed anymore, just use usb_stor_dbg() instead. 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: [PATCH v7 0/3] usbip: exporting devices
> I have no idea what you mean by "exporting devices" :( It's at line 86 of original tools/usb/usbip/src/usbip_network.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: [PATCH v7 0/3] usbip: exporting devices
On Mon, Feb 15, 2016 at 01:23:20AM +, fx IWATA NOBUO wrote: > > I have no idea what you mean by "exporting devices" :( > > It's at line 86 of original tools/usb/usbip/src/usbip_network.h > // I have no idea what you are talking about here, please be more descriptive in the changelog. And as we already "export devices" with usbip, I don't see why you are changing anything, as obviously we already do it :) 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
[PATCH v4] usb: devio: Add ioctl to disallow detaching kernel USB drivers.
From: Reilly Grant
The new USBDEVFS_DROP_PRIVILEGES ioctl allows a process to voluntarily
relinquish the ability to issue other ioctls that may interfere with
other processes and drivers that have claimed an interface on the
device.
This commit also includes a simple utility to be able to test the
ioctl, located at Documentation/usb/usbdevfs-drop-permissions.c
Example (with qemu-kvm's input device):
$ lsusb
...
Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd
$ usb-devices
...
C: #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=02 Driver=usbhid
$ sudo ./usbdevfs-drop-permissions /dev/bus/usb/001/002
OK: privileges dropped!
Available options:
[0] Exit now
[1] Reset device. Should fail if device is in use
[2] Claim 4 interfaces. Should succeed where not in use
[3] Narrow interface permission mask
Which option shall I run?: 1
ERROR: USBDEVFS_RESET failed! (1 - Operation not permitted)
Which test shall I run next?: 2
ERROR claiming if 0 (1 - Operation not permitted)
ERROR claiming if 1 (1 - Operation not permitted)
ERROR claiming if 2 (1 - Operation not permitted)
ERROR claiming if 3 (1 - Operation not permitted)
Which test shall I run next?: 0
After unbinding usbhid:
$ usb-devices
...
I: If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=02 Driver=(none)
$ sudo ./usbdevfs-drop-permissions /dev/bus/usb/001/002
...
Which option shall I run?: 2
OK: claimed if 0
ERROR claiming if 1 (1 - Operation not permitted)
ERROR claiming if 2 (1 - Operation not permitted)
ERROR claiming if 3 (1 - Operation not permitted)
Which test shall I run next?: 1
OK: USBDEVFS_RESET succeeded
Which test shall I run next?: 0
After unbinding usbhid and restricting the mask:
$ sudo ./usbdevfs-drop-permissions /dev/bus/usb/001/002
...
Which option shall I run?: 3
Insert new mask: 0
OK: privileges dropped!
Which test shall I run next?: 2
ERROR claiming if 0 (1 - Operation not permitted)
ERROR claiming if 1 (1 - Operation not permitted)
ERROR claiming if 2 (1 - Operation not permitted)
ERROR claiming if 3 (1 - Operation not permitted)
Signed-off-by: Reilly Grant
Signed-off-by: Emilio López
---
Changes in v4:
- IOR -> IOW
- Explain the new ioctl on usb Docbook
- Small program to be able to test the new functionality
- New capability flag
- Allow people to reset devices if they are the only ones
claiming interfaces, as suggested by Alan
Changes in v3:
- Switch ioctl to use a __u32 given the iface qty is capped at 32
- Reword comments as requested by Alan
- Allow callers to shrink the allowed interfaces mask
Changes in v2:
- Added a parameter to the ioctl, a mask of interfaces an unprivileged
process is allowed to claim.
- Drop Tested-by's
Documentation/DocBook/usb.tmpl| 12 +++
Documentation/usb/usbdevfs-drop-permissions.c | 120 ++
drivers/usb/core/devio.c | 63 --
include/uapi/linux/usbdevice_fs.h | 2 +
4 files changed, 192 insertions(+), 5 deletions(-)
create mode 100644 Documentation/usb/usbdevfs-drop-permissions.c
diff --git a/Documentation/DocBook/usb.tmpl b/Documentation/DocBook/usb.tmpl
index 4cd5b2c..bc776be0 100644
--- a/Documentation/DocBook/usb.tmpl
+++ b/Documentation/DocBook/usb.tmpl
@@ -732,6 +732,18 @@ usbdev_ioctl (int fd, int ifno, unsigned request, void
*param)
or SET_INTERFACE.
+ USBDEVFS_DROP_PRIVILEGES
+ This is used to relinquish the ability
+ to do certain operations which are considered to be
+ privileged on a usbfs file descriptor.
+ This includes claiming arbitrary interfaces, resetting
+ a device on which there are currently claimed interfaces
+ from other users, and issuing USBDEVFS_IOCTL calls.
+ The ioctl parameter is a 32 bit mask of interfaces
+ the user is allowed to claim on this file descriptor.
+ You may issue this ioctl more than one time to narrow
+ said mask.
+
diff --git a/Documentation/usb/usbdevfs-drop-permissions.c
b/Documentation/usb/usbdevfs-drop-permissions.c
new file mode 100644
index 000..efc948a
--- /dev/null
+++ b/Documentation/usb/usbdevfs-drop-permissions.c
@@ -0,0 +1,120 @@
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+/* For building without an updated set of headers */
+#ifndef USBDEVFS_DROP_PRIVILEGES
+#define USBDEVFS_DROP_PRIVILEGES _IOW('U', 30, __u32)
+#define USBDEVFS_CAP_DROP_PRIVILEGES 0x20
+#endif
+
+void drop_privileges(int fd, uint32_t mask)
+{
+ int
RE: [PATCH v3 1/2] usbip: vhci number of ports extension
> > ex) # insmod vhci_hcd.ko num_controllers=4 > > I hate module parameters, please don't do that, create these dynamically > as needed some other way. OK. > > Also, ports per controller is changed from 8 to USB_MAXCHILDREN (31). > > Why? All in one patch? Not good. I will remove the modification. > > It can be modified with VHCI_NPORTS flag at module compilation. > > No one does that, make this dynamic as well please, in a series of patches, > not just one huge one. OK. By the way, how about 2/2. If it's acceptable, I will post it excluding 1/2. Thank you, n.iwata // -- 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 v7 1/3] usbip: exporting devices
> That's too much code to review, especially for something that I have no > idea what it is, or why it is needed at all. > > Please be more descriptive here, and hopefully, break this patch down into > smaller steps. OK. I will divide. Best Regards, n.iwata // -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v6 00/10] add HNP polling support for usb otg fsm
Resend with Felipe's new email address > -Original Message- > From: Jun Li > Sent: Monday, February 15, 2016 10:16 AM > To: ba...@ti.com > Cc: linux-usb@vger.kernel.org; Peter Chen ; > hzpeterc...@gmail.com; gre...@linuxfoundation.org; Jun Li > Subject: RE: [PATCH v6 00/10] add HNP polling support for usb otg fsm > > Ping... > > > -Original Message- > > From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb- > > ow...@vger.kernel.org] On Behalf Of Jun Li > > Sent: Thursday, January 28, 2016 2:50 PM > > To: ba...@ti.com > > Cc: linux-usb@vger.kernel.org; Peter Chen ; > > hzpeterc...@gmail.com; gre...@linuxfoundation.org > > Subject: RE: [PATCH v6 00/10] add HNP polling support for usb otg fsm > > > > Hi Felipe, > > > > > -Original Message- > > > From: Jun Li > > > Sent: Tuesday, January 26, 2016 3:19 PM > > > To: Peter Chen ; hzpeterc...@gmail.com; > > > ba...@ti.com; gre...@linuxfoundation.org > > > Cc: linux-usb@vger.kernel.org; Jun Li > > > Subject: [PATCH v6 00/10] add HNP polling support for usb otg fsm > > > > > > HNP polling is a mechanism which allows the OTG device currently > > > acting as host to determine when the other attached OTG device > > > wishes to take the host role. When an OTG host, which supports HNP, > > > is connected to an OTG peripheral which also supports HNP it shall > > > poll the peripheral regularly to determine whether it requires a > > > role-swap and grant this at the earliest opportunity. > > > This patchset adds OTG HNP polling support, and enable for chipidea > > > usb otg fsm driver, more patches for pass OTG certification will > > > come > > later. > > > > > > changes for v6: > > > - Remove patch of disable irq while stop host role. > > > - Split B_AIDL_BDIS timer patch to be 2 patches(9/10 and 10/10). > > > - Add Peter's ack for patch 3, 7, 8/10. > > > > > > changes for v5: > > > - Instead of use stack memory, use kmalloc to allocate memory for host > > > request flag one byte buffer(DMA read), and add host_req_flag > pointer > > > in struct otg_fsm for reference to that flag buffer. > > > - Add one patch to disable irq while stop host role(7/10). > > > - Add one patch to fix B_AIDL_BDIS timing issue(10/10). > > > > > > changes for v4: > > > - Add OTG HNP capable check for connected device before sending HNP > > > polling > > > in patch 3/8. > > > - Add comment to explain HNP test update in chipidea.txt in patch 8/8. > > > - Fix some typo. > > > - Add Peter's Ack in patch 1,2,4,5,6,7/8 of the series. > > > > > > Li Jun (10): > > > usb: gadget: add hnp_polling_support and host_request_flag in > > > usb_gadget > > > usb: add OTG status selector definition for HNP polling > > > usb: common: otg-fsm: add HNP polling support > > > usb: chipidea: udc: bypass otg status selector handling to gadget > > > driver > > > usb: gadget: composite: handle otg status selector request from OTG > > > host > > > usb: chipidea: otg: set host_request_flag for gadget > > > usb: chipidea: otg: enable HNP polling support for gadget and host > > > Documentation: usb: chipidea: Update test procedure for HNP polling > > > usb: otg-fsm: add B_AIDL_BDIS timer > > > usb: chipidea: otg: add A idle to B disconnect timer > > > > > > Documentation/usb/chipidea.txt | 9 +++-- > > > drivers/usb/chipidea/otg_fsm.c | 29 -- > > > drivers/usb/chipidea/otg_fsm.h | 2 + > > > drivers/usb/chipidea/udc.c | 3 +- > > > drivers/usb/common/usb-otg-fsm.c | 87 > > > > > > drivers/usb/gadget/composite.c | 25 > > > include/linux/usb/gadget.h | 6 +++ > > > include/linux/usb/otg-fsm.h | 15 +++ > > > include/uapi/linux/usb/ch9.h | 1 + > > > 9 files changed, 161 insertions(+), 16 deletions(-) > > > > > > -- > > > 1.9.1 > > > > Could you please take look this series again? Basically this is a > > updated version based on v4 you reviewed, for common and gadget part, > > the only major change is use dedicated buffer through kmalloc instead > > of use a stack variable for host request flag(usb control transfer, DMA > read). > > Other changes are for chipidea driver. > > The common HNP polling implementation is generic so does not depend on > > any specific controller drivers, also Roger's OTG core. If you still > > think the chipidea driver ABI change is not in right direction since > > Roger will introduce OTG core concept, I can drop that part. > > > > Thanks! > > Li Jun > > > > -- > > 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 v6 00/10] add HNP polling support for usb otg fsm
Ping... > -Original Message- > From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb- > ow...@vger.kernel.org] On Behalf Of Jun Li > Sent: Thursday, January 28, 2016 2:50 PM > To: ba...@ti.com > Cc: linux-usb@vger.kernel.org; Peter Chen ; > hzpeterc...@gmail.com; gre...@linuxfoundation.org > Subject: RE: [PATCH v6 00/10] add HNP polling support for usb otg fsm > > Hi Felipe, > > > -Original Message- > > From: Jun Li > > Sent: Tuesday, January 26, 2016 3:19 PM > > To: Peter Chen ; hzpeterc...@gmail.com; > > ba...@ti.com; gre...@linuxfoundation.org > > Cc: linux-usb@vger.kernel.org; Jun Li > > Subject: [PATCH v6 00/10] add HNP polling support for usb otg fsm > > > > HNP polling is a mechanism which allows the OTG device currently > > acting as host to determine when the other attached OTG device wishes > > to take the host role. When an OTG host, which supports HNP, is > > connected to an OTG peripheral which also supports HNP it shall poll > > the peripheral regularly to determine whether it requires a role-swap > > and grant this at the earliest opportunity. > > This patchset adds OTG HNP polling support, and enable for chipidea > > usb otg fsm driver, more patches for pass OTG certification will come > later. > > > > changes for v6: > > - Remove patch of disable irq while stop host role. > > - Split B_AIDL_BDIS timer patch to be 2 patches(9/10 and 10/10). > > - Add Peter's ack for patch 3, 7, 8/10. > > > > changes for v5: > > - Instead of use stack memory, use kmalloc to allocate memory for host > > request flag one byte buffer(DMA read), and add host_req_flag pointer > > in struct otg_fsm for reference to that flag buffer. > > - Add one patch to disable irq while stop host role(7/10). > > - Add one patch to fix B_AIDL_BDIS timing issue(10/10). > > > > changes for v4: > > - Add OTG HNP capable check for connected device before sending HNP > > polling > > in patch 3/8. > > - Add comment to explain HNP test update in chipidea.txt in patch 8/8. > > - Fix some typo. > > - Add Peter's Ack in patch 1,2,4,5,6,7/8 of the series. > > > > Li Jun (10): > > usb: gadget: add hnp_polling_support and host_request_flag in > > usb_gadget > > usb: add OTG status selector definition for HNP polling > > usb: common: otg-fsm: add HNP polling support > > usb: chipidea: udc: bypass otg status selector handling to gadget > > driver > > usb: gadget: composite: handle otg status selector request from OTG > > host > > usb: chipidea: otg: set host_request_flag for gadget > > usb: chipidea: otg: enable HNP polling support for gadget and host > > Documentation: usb: chipidea: Update test procedure for HNP polling > > usb: otg-fsm: add B_AIDL_BDIS timer > > usb: chipidea: otg: add A idle to B disconnect timer > > > > Documentation/usb/chipidea.txt | 9 +++-- > > drivers/usb/chipidea/otg_fsm.c | 29 -- > > drivers/usb/chipidea/otg_fsm.h | 2 + > > drivers/usb/chipidea/udc.c | 3 +- > > drivers/usb/common/usb-otg-fsm.c | 87 > > > > drivers/usb/gadget/composite.c | 25 > > include/linux/usb/gadget.h | 6 +++ > > include/linux/usb/otg-fsm.h | 15 +++ > > include/uapi/linux/usb/ch9.h | 1 + > > 9 files changed, 161 insertions(+), 16 deletions(-) > > > > -- > > 1.9.1 > > Could you please take look this series again? Basically this is a updated > version based on v4 you reviewed, for common and gadget part, the only > major change is use dedicated buffer through kmalloc instead of use a > stack variable for host request flag(usb control transfer, DMA read). > Other changes are for chipidea driver. > The common HNP polling implementation is generic so does not depend on any > specific controller drivers, also Roger's OTG core. If you still think the > chipidea driver ABI change is not in right direction since Roger will > introduce OTG core concept, I can drop that part. > > Thanks! > Li Jun > > -- > 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 v7 2/3] usbip: readme and manuals about exporting devices
> > This patch adds function and usage of export to README and manuals. > > > > The wording, 'server' and 'client' are changed. > > That sounds like a mistake, why would you do that? You just reversed > everything? Why? I'd like to add reverse connection. Originally both IMPORT and EXPORT packet is defined in tools/usb/usbip/src/usbip_network.h IMPORT has been implemented but EXPORT is not. For IMPORT command, server (daemon) runs in stub side and client (ATTACH command) is executed in vhci side. For EXPORT command, server must run in stub side and client must be stub side. I thought user want to know where device is connected and application is running. Only for IMPORT, wording 'server' and 'client' is enough. To explain both, I thought the wording is not good for user. > > For existing attach command, the daemon runs device side machine and > > attach command is executed in application side machine. Then 'server' > > is used for device side and 'client' is for application side. > > > > For the new connect command, the daemon runs applications side machine > > and connect command is executed in device side machine. Now, 'server' > > and 'client' run in different machine than before. > > So you just broke everything that was working before? That's not > acceptable :( No. I don't think so. I carefully keep existing functions and just add. Thank you, n.iwata // -- 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 v7 1/3] usbip: exporting devices
> I don't see any benifit here at all, please explain it better. > You are saying what your patch does, but not why we would want it. It may not be better than cover letter but I try. My use case is a) a service in internet with VHCI b) distributed small Linux nodes with STUB and IoT devices. IoT device may be inside firewall. To pass firewall, usually WebSocket is used. It can be added tunneling daemon in both side. Connection must be initiated from device side. This is the most important for my use case. In the use case, there may be no operator checking device. Device may be plug-and-played. For security consideration, client verification be the tunneling daemon. n.iwata // -- 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 BACKPORT] xhci:_don't_finish_a_TD_if_we_get_a_short_transfer_event_mid_TD
On Sun, 2016-02-14 at 14:15 -0800, Greg KH wrote: > On Wed, Dec 16, 2015 at 06:22:30AM -0800, Steve Bangert wrote: > > Hi, > > > > This original patch was posted and applied to the 4.3-rcX kernel > > and tagged for > > stable kernels. > > > > http://marc.info/?l=linux-usb&m=144463835322214&w=2 > > > > > > But didn't to make it into the 4.1 and 3.14 kernels as it failed > > to apply in it's original form. > > > > A backport from Ben Hutchings was posted during the 3.2.73-rc1 > > review cycle and will now apply. > > > > Please consider for the next stable kernel release cycle. > > Patch is corrupted and does not apply properly :( > You can disregard as the patch was reverted upstream. Steve -- 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 20/21] usb: support building without CONFIG_HAS_DMA
On 02/15/2016 02:09 AM, Greg Kroah-Hartman wrote: On Wed, Feb 10, 2016 at 03:29:55PM +0100, Vegard Nossum wrote: Some platforms don't have DMA, but we should still be able to build USB drivers for these platforms. They could still be used through vhci_hcd, usbip_host, or maybe something like USB passthrough in UML from a capable host. This is admittedly ugly with all the #ifdefs, but it is necessary to get around linker errors like these: Sorry, you are going to have to do something else here, I can't accept this patch, it's just too ugly to read :( Ok, I'll work on an alternative. Thanks for the feedback ;-) Vegard -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 0/2] usbip: vhci number of ports extension
> What limitation? Why change it? What's the problem here... In original code, number of devices to be able to attach is 8. It's came from VHCI_NPORTS, the default is 8. It can be changed with compile option -DVHCI_NPORTS The maximum number is limited to USB_MAXCHILDREN (31). In my use case, service is in internet and need more devices than 8 or 31 to be served. Linux is major as internet service platform and also IoT nodes. I thought there's someone needs same extension. Thank you, n.iwata // -- 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 v7 3/3] usbip: safe completion against usb_kill_urb()
> Why this one tiny bugfix at the end of this series? Is this something that > could be applied without the huge 1/3 patch here? If so, please send it > on its own. If not, then please fix it in the place where you made this > bug happen. OK. I will send it separately. I will send it as V1 with description that spawned from the series. If it's no good, please, let me know. Many thanks, n.iwata // -- 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 3/7] usb: gadget: pxa25x_udc: use readl/writel for mmio
Arnd Bergmann writes: >> Anyway, I think readl()/writel() do the right thing: in BE mode they >> swap PCI accesses and don't swap normal registers, in LE mode nothing is >> swapped. > > This seems to be true when CONFIG_IXP4XX_INDIRECT_PCI is set, but > not otherwise. For the indirect variant, writel() is a __raw_writel() > without barrier or byteswap on non-PCI memory, while with that > option disabled, we use the standard implementation that has both > a byteswap and a barrier. > > According to your description, that would mean the version without > indirect PCI access is broken and it appears to have been that way > since before the start of git history in 2.6.12. > > It's possible that nobody cared because all drivers for non-PCI > devices on ixp4xx (the on chip ones) just use __raw_readl or > direct pointer references. Well, it is possible. I recall I probably used __raw_* instead of readl()/writel() in qmgr/npe/Ethernet drivers for this very reason. I think Direct pointer references are only used for locations in RAM (DMA buffers), they have their own share of problems because the peripherals are always big endian. I think I still have an early IXP425 board with UDC connector so I will try to dig it up and test this code. I wonder if we should switch the driver to use __raw_*, too. The problem is almost nobody uses UDC with this CPU. -- Krzysztof Halasa Industrial Research Institute for Automation and Measurements PIAP Al. Jerozolimskie 202, 02-486 Warsaw, Poland -- 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
