[GIT PULL] USB driver fixes for 4.9-rc5
The following changes since commit a909d3e636995ba7c349e2ca5dbb528154d4ac30: Linux 4.9-rc3 (2016-10-29 13:52:02 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-4.9-rc5 for you to fetch changes up to 18266403f3fe507f0246faa1d5432333a2f139ca: USB: cdc-acm: fix TIOCMIWAIT (2016-11-10 13:12:59 +0100) USB / PHY fixes for 4.9-rc5 Here are a number of small USB and PHY driver fixes for 4.9-rc5 Nothing major, just small fixes for reported issues, all of these have been in linux-next for a while with no reported issues. Signed-off-by: Greg Kroah-Hartman Axel Haslam (1): phy: da8xx-usb: rename the ohci device to ohci-da8xx Babu Moger (1): drivers/usb: Skip auto handoff for TI and RENESAS usb controllers David Lechner (1): usb: musb: da8xx: Don't print phy error on -EPROBE_DEFER Felipe Balbi (2): usb: dwc3: st: add missing include usb: gadget: u_ether: remove interrupt throttling Greg Kroah-Hartman (2): Merge tag 'fixes-for-v4.9-rc4' of git://git.kernel.org/.../balbi/usb into usb-linus Merge tag 'phy-for-4.9-rc' of git://git.kernel.org/.../kishon/linux-phy into usb-linus Icenowy Zheng (1): phy: sun4i: check PMU presence when poking unknown bit of pmu Johan Hovold (2): uwb: fix device reference leaks USB: cdc-acm: fix TIOCMIWAIT Kirill Esipov (1): usb: musb: remove duplicated actions Oliver Neukum (1): cdc-acm: fix uninitialized variable Randy Li (1): phy: Add reset callback for not generic phy Shawn Lin (1): phy-rockchip-pcie: remove deassert of phy_rst from exit callback Vivek Gautam (1): usb: dwc3: Fix error handling for core init drivers/phy/phy-da8xx-usb.c | 5 +++-- drivers/phy/phy-rockchip-pcie.c | 13 + drivers/phy/phy-sun4i-usb.c | 2 +- drivers/usb/class/cdc-acm.c | 4 ++-- drivers/usb/dwc3/core.c | 5 ++--- drivers/usb/dwc3/dwc3-st.c| 1 + drivers/usb/gadget/function/u_ether.c | 8 drivers/usb/host/pci-quirks.c | 8 drivers/usb/musb/da8xx.c | 3 ++- drivers/usb/musb/musb_core.c | 5 - drivers/uwb/lc-rc.c | 16 +--- drivers/uwb/pal.c | 2 ++ include/linux/phy/phy.h | 7 +++ 13 files changed, 42 insertions(+), 37 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
[PATCH] usb: core: urb make use of usb_endpoint_maxp_mult
Since usb_endpoint_maxp now returns only lower 11 bits mult
calculation here isn't correct anymore and that breaks webcam
for me. Patch make use of usb_endpoint_maxp_mult instead of
direct calculation.
Fixes: abb621844f6a ("usb: ch9: make usb_endpoint_maxp() return
only packet size")
Signed-off-by: Mike Krinkin
---
drivers/usb/core/urb.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/core/urb.c b/drivers/usb/core/urb.c
index 0be49a1..d75cb8c 100644
--- a/drivers/usb/core/urb.c
+++ b/drivers/usb/core/urb.c
@@ -412,11 +412,8 @@ int usb_submit_urb(struct urb *urb, gfp_t mem_flags)
}
/* "high bandwidth" mode, 1-3 packets/uframe? */
- if (dev->speed == USB_SPEED_HIGH) {
- int mult = 1 + ((max >> 11) & 0x03);
- max &= 0x07ff;
- max *= mult;
- }
+ if (dev->speed == USB_SPEED_HIGH)
+ max *= usb_endpoint_maxp_mult(&ep->desc);
if (urb->number_of_packets <= 0)
return -EINVAL;
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] mmc: allow mmc_alloc_host() and tmio_mmc_host_alloc()
On Fri, Nov 11, 2016 at 12:19:05PM +0900, Masahiro Yamada wrote: > 2016-11-10 22:35 GMT+09:00 Greg Kroah-Hartman : > > On Thu, Nov 10, 2016 at 10:24:21PM +0900, Masahiro Yamada wrote: > >> > >> sdhci_alloc_host() returns an error pointer when it fails. > >> but mmc_alloc_host() cannot. > >> > >> This series allow to propagate a proper error code > >> when host-allocation fails. > > > > Why? What can we really do about the error except give up? Why does > > having a explicit error value make any difference to the caller, they > > can't do anything different, right? > > > The error code is shown in the console, like > > probe of 5a00.sdhc failed with error -12 > > > The proper error code will give a clue why the driver failed to probe. Can't the mmc core show the reason once, and not require each and every individual driver to show/say the same thing? All a driver needs to know is if it worked or didn't work. Every time it didn't work, it needs to unwind stuff and then recover properly. The drivers do not do different things based on what type of error happened, as they don't care at all. So I strongly suggest leaving it simple, as it is today, as this makes drivers simpler, they don't have to duplicate the same type of error reporting all over the place, and it's easy to audit for. It also makes it so that large patchsets that touch every driver like this are not needed at all. > > I suggest just leaving it as-is, it's simple, and you don't have to mess > > with PTR_ERR() anywhere. > > > Why? > > Most of driver just give up probing for any error, > but we still do ERR_PTR()/PTR_ERR() here and there. > I think this patch is the same pattern. I think we need to get rid of more of the ERR_PTR() stuff, as again, it's useless. All we need to know is an error happened, that's it. > If a function returns NULL on failure, we need to think about > "what is the most common failure case". > > Currently, MMC drivers assume -ENOMEM is the best > fit for mmc_alloc_host(), but the assumption is fragile. > > Already, mmc_alloc_host() calls a function > that returns not only -ENOMEM, but also -ENOSPC. > > In the future, some other failure cases might be > added to mmc_alloc_host(). > > Once we decide the API returns an error pointer, > drivers just propagate the return value from the API. > This is much more stable implementation. Again, no, it makes more work for the different drivers, duplicates code all over the place, and really doesn't help any user, or developer, out at all. Just have the mmc core properly log what went wrong, and all should be fine. Again, keep it simple, that's the best policy for the kernel, and really, most software :) 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 v5] USB hub_probe: rework ugly goto-into-compound-statement
Rework smelling code (goto inside compound statement). Perhaps this is
legacy. Anyway such code is not appropriate for Linux kernel.
Signed-off-by: Eugene Korenevsky
---
Changes in v5: make `bool` a return type of `hub_check_descriptor_sanity()`
Changes in v4: fix typo
Changes in v3: extract the code to static function
Changes in v2: fix spaces instead of tab, add missing 'Signed-off-by'
drivers/usb/core/hub.c | 35 ++-
1 file changed, 18 insertions(+), 17 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index cbb1467..1a316a1 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1722,10 +1722,25 @@ static void hub_disconnect(struct usb_interface *intf)
kref_put(&hub->kref, hub_release);
}
+static bool hub_check_descriptor_sanity(struct usb_host_interface *desc)
+{
+ /* Some hubs have a subclass of 1, which AFAICT according to the */
+ /* specs is not defined, but it works */
+ if (desc->desc.bInterfaceSubClass != 0 &&
+ desc->desc.bInterfaceSubClass != 1)
+ return false;
+
+ /* Multiple endpoints? What kind of mutant ninja-hub is this? */
+ if (desc->desc.bNumEndpoints != 1)
+ return false;
+
+ /* If it's not an interrupt in endpoint, we'd better punt! */
+ return usb_endpoint_is_int_in(&desc->endpoint[0].desc) != 0;
+}
+
static int hub_probe(struct usb_interface *intf, const struct usb_device_id
*id)
{
struct usb_host_interface *desc;
- struct usb_endpoint_descriptor *endpoint;
struct usb_device *hdev;
struct usb_hub *hub;
@@ -1800,25 +1815,11 @@ static int hub_probe(struct usb_interface *intf, const
struct usb_device_id *id)
}
#endif
- /* Some hubs have a subclass of 1, which AFAICT according to the */
- /* specs is not defined, but it works */
- if ((desc->desc.bInterfaceSubClass != 0) &&
- (desc->desc.bInterfaceSubClass != 1)) {
-descriptor_error:
+ if (!hub_check_descriptor_sanity(desc)) {
dev_err(&intf->dev, "bad descriptor, ignoring hub\n");
return -EIO;
}
- /* Multiple endpoints? What kind of mutant ninja-hub is this? */
- if (desc->desc.bNumEndpoints != 1)
- goto descriptor_error;
-
- endpoint = &desc->endpoint[0].desc;
-
- /* If it's not an interrupt in endpoint, we'd better punt! */
- if (!usb_endpoint_is_int_in(endpoint))
- goto descriptor_error;
-
/* We found a hub */
dev_info(&intf->dev, "USB hub found\n");
@@ -1845,7 +1846,7 @@ static int hub_probe(struct usb_interface *intf, const
struct usb_device_id *id)
if (id->driver_info & HUB_QUIRK_CHECK_PORT_AUTOSUSPEND)
hub->quirk_check_port_auto_suspend = 1;
- if (hub_configure(hub, endpoint) >= 0)
+ if (hub_configure(hub, &desc->endpoint[0].desc) >= 0)
return 0;
hub_disconnect(intf);
--
2.10.2
--
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] r8152: Fix error path in open function
From: Guenter Roeck Date: Wed, 9 Nov 2016 19:51:25 -0800 > If usb_submit_urb() called from the open function fails, the following > crash may be observed. ... > Clean up error handling to avoid registering the notifier if the open > function is going to fail. > > Signed-off-by: Guenter Roeck Looks good, applied, thanks. -- 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 net 2/2] r8152: rx descriptor check
From: Hayes Wang Date: Fri, 11 Nov 2016 15:15:41 +0800 > For some platforms, the data in memory is not the same with the one > from the device. That is, the data of memory is unbelievable. The > check is used to find out this situation. > > Signed-off-by: Hayes Wang I'm all for adding consistency checks, but I disagree with proceeding in this manner for this. If you add this patch now, there is a much smaller likelyhood that you will work with a high priority to figure out _why_ this is happening. For all we know this could be a platform bug in the DMA API for the systems in question. It could also be a bug elsewhere in the driver, either in setting up the descriptor DMA mappings or how the chip is programmed. Either way the true cause must be found before we start throwing changes like this into the driver. I'm not applying this series, sorry. -- 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
Odp: Re: Problem: booting from Sandisk USB stick fails
Dnia Czwartek, 7 Lipca 2016 01:08 Greg KH napisał(a) > On Wed, Jul 06, 2016 at 08:00:55PM +0200, Ziutek Putek wrote: > > [1.] Booting from Sandisk USB stick fails and stops on Dell Latitude E5420 > > Laptop. > > > > [2.] On mainline kernel I get error: > > [ 18.414128] usb 2-1.4: device descriptor read/64, error -110 > > [ 23.601028] usb 2-1.4: device descriptor read/64, error -71 > > [ 23.777126] usb 2-1.4: new high-speed USB device number 4 using ehci-pci > > [ 23.861176] usb 2-1.4: device descriptor read/64, error -71 > > [ 24.049280] usb 2-1.4: device descriptor read/64, error -71 > > [ 24.225377] usb 2-1.4: new high-speed USB device number 5 using ehci-pci > > [ 24.641614] usb 2-1.4: device not accepting address 5, error -71 > > [ 24.713649] usb 2-1.4: new high-speed USB device number 6 using ehci-pci > > [ 25.129882] usb 2-1.4: device not accepting address 6, error -71 > > [ 25.131599] usb 2-1-port4: unable to enumerate USB device > > > > however unpluging and repluging usb stick makes booting process go further. > > > > On upstream kernel these errors do not show at all and the workaround with > > unplugging and repluging usb stick does not work. > > What do you mean "upstream" and "mainline"? > > Which version works? Which version does not? > > thanks, > > greg k-h It seems that the problem disappeared after upgrade to 4.4.0-47-generic #68-Ubuntu. Best regards Darek -- 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 net 2/2] r8152: rx descriptor check
On 16-11-13 12:39 PM, David Miller wrote: > From: Hayes Wang > Date: Fri, 11 Nov 2016 15:15:41 +0800 > >> For some platforms, the data in memory is not the same with the one >> from the device. That is, the data of memory is unbelievable. The >> check is used to find out this situation. >> >> Signed-off-by: Hayes Wang > > I'm all for adding consistency checks, but I disagree with proceeding > in this manner for this. > > If you add this patch now, there is a much smaller likelyhood that you > will work with a high priority to figure out _why_ this is happening. > > For all we know this could be a platform bug in the DMA API for the > systems in question. > > It could also be a bug elsewhere in the driver, either in setting up > the descriptor DMA mappings or how the chip is programmed. > > Either way the true cause must be found before we start throwing > changes like this into the driver. I agree. The system I use it with is a 32-bit ppc476, with non-coherent RAM, and using 16KB page sizes. The dongle instantly becomes a lot more reliable when r8152.c is updated to use usb_alloc_coherent() for URB buffers, rather than kmalloc(). Not sure why that would be though, as the USB stack normally would handle kmalloc'd buffers just fine. It is calling the appropriate routines, which boil down to invalidating the dcache lines (for inbound bulk xfers) as part of usb_submit_urb(), and yet the problem there persists. It could be caused by cache-line sharing with other allocations, but that seems unlikely as the kmalloc() size is 16384 bytes per buffer. Perhaps the driver is somehow accessing the buffer space again after doing usb_submit_urb()? That would certainly produce this kind of behaviour. Or maybe there's just a memory barrier missing somewhere in path. The really weird thing is that ASIX-based dongles (which use a different driver) don't have this problem, and yet they also use kmalloc'd buffers. I have access to the test system only for a day or two a week, and it takes a few hours to do a good test as to whether something helps or not. I'll continue to poke at it as time and New Ideas permit. New Ideas welcome! -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- 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 net 2/2] r8152: rx descriptor check
On 16-11-13 03:34 PM, Mark Lord wrote: > > The system I use it with is a 32-bit ppc476, with non-coherent RAM, > and using 16KB page sizes. > > The dongle instantly becomes a lot more reliable when r8152.c is updated > to use usb_alloc_coherent() for URB buffers, rather than kmalloc(). > > Not sure why that would be though, as the USB stack normally would handle > kmalloc'd buffers just fine. It is calling the appropriate routines, > which boil down to invalidating the dcache lines (for inbound bulk xfers) > as part of usb_submit_urb(), and yet the problem there persists. > > It could be caused by cache-line sharing with other allocations, but that > seems > unlikely as the kmalloc() size is 16384 bytes per buffer. Perhaps the driver > is somehow accessing the buffer space again after doing usb_submit_urb()? > That would certainly produce this kind of behaviour. > > Or maybe there's just a memory barrier missing somewhere in path. > > The really weird thing is that ASIX-based dongles (which use a different > driver) > don't have this problem, and yet they also use kmalloc'd buffers. > > I have access to the test system only for a day or two a week, > and it takes a few hours to do a good test as to whether something helps or > not. > I'll continue to poke at it as time and New Ideas permit. Oh, and the problems did not exist with the 3.14.xx kernels and earlier. They began to show up when we tried 3.16.xx and all newer kernels. The difference there is that RX checksums were enabled in hardware as of 3.16.xx, and thus the network stack began accepting bad packets from the r8152 driver. I don't know if the ASIX driver uses hardware checksums or just software checksums. That might explain why it is more reliable here. -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: mtu3: declare functions static
The only user of the functions mtu3_irq() and gpd_ring_empty() are in
the same file. They can be declared as static.
Signed-off-by: Sudip Mukherjee
---
drivers/usb/mtu3/mtu3_core.c | 2 +-
drivers/usb/mtu3/mtu3_qmu.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/mtu3/mtu3_core.c b/drivers/usb/mtu3/mtu3_core.c
index 520e55a..603b7f84 100644
--- a/drivers/usb/mtu3/mtu3_core.c
+++ b/drivers/usb/mtu3/mtu3_core.c
@@ -696,7 +696,7 @@ static irqreturn_t mtu3_u2_common_isr(struct mtu3 *mtu)
return IRQ_HANDLED;
}
-irqreturn_t mtu3_irq(int irq, void *data)
+static irqreturn_t mtu3_irq(int irq, void *data)
{
struct mtu3 *mtu = (struct mtu3 *)data;
unsigned long flags;
diff --git a/drivers/usb/mtu3/mtu3_qmu.c b/drivers/usb/mtu3/mtu3_qmu.c
index a6dd292..7d9ba8a 100644
--- a/drivers/usb/mtu3/mtu3_qmu.c
+++ b/drivers/usb/mtu3/mtu3_qmu.c
@@ -168,7 +168,7 @@ static struct qmu_gpd *advance_deq_gpd(struct mtu3_gpd_ring
*ring)
}
/* check if a ring is emtpy */
-int gpd_ring_empty(struct mtu3_gpd_ring *ring)
+static int gpd_ring_empty(struct mtu3_gpd_ring *ring)
{
struct qmu_gpd *enq = ring->enqueue;
struct qmu_gpd *next;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v10 1/8] binding-doc: power: pwrseq-generic: add binding doc for generic power sequence library
Add binding doc for generic power sequence library.
Signed-off-by: Peter Chen
Acked-by: Philipp Zabel
Acked-by: Rob Herring
---
.../bindings/power/pwrseq/pwrseq-generic.txt | 48 ++
1 file changed, 48 insertions(+)
create mode 100644
Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
diff --git a/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
new file mode 100644
index 000..ebf0d47
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
@@ -0,0 +1,48 @@
+The generic power sequence library
+
+Some hard-wired devices (eg USB/MMC) need to do power sequence before
+the device can be enumerated on the bus, the typical power sequence
+like: enable USB PHY clock, toggle reset pin, etc. But current
+Linux device driver lacks of such code to do it, it may cause some
+hard-wired devices works abnormal or can't be recognized by
+controller at all. The power sequence will be done before this device
+can be found at the bus.
+
+The power sequence properties is under the device node.
+
+Optional properties:
+- clocks: the input clocks for device.
+- reset-gpios: Should specify the GPIO for reset.
+- reset-duration-us: the duration in microsecond for assert reset signal.
+
+Below is the example of USB power sequence properties on USB device
+nodes which have two level USB hubs.
+
+&usbotg1 {
+ vbus-supply = <®_usb_otg1_vbus>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usb_otg1_id>;
+ status = "okay";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ genesys: hub@1 {
+ compatible = "usb5e3,608";
+ reg = <1>;
+
+ clocks = <&clks IMX6SX_CLK_CKO>;
+ reset-gpios = <&gpio4 5 GPIO_ACTIVE_LOW>; /* hub reset pin */
+ reset-duration-us = <10>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ asix: ethernet@1 {
+ compatible = "usbb95,1708";
+ reg = <1>;
+
+ clocks = <&clks IMX6SX_CLK_IPG>;
+ reset-gpios = <&gpio4 6 GPIO_ACTIVE_LOW>; /*
ethernet_rst */
+ reset-duration-us = <15>;
+ };
+ };
+};
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v10 2/8] power: add power sequence library
We have an well-known problem that the device needs to do some power sequence before it can be recognized by related host, the typical example like hard-wired mmc devices and usb devices. This power sequence is hard to be described at device tree and handled by related host driver, so we have created a common power sequence library to cover this requirement. The core code has supplied some common helpers for host driver, and individual power sequence libraries handle kinds of power sequence for devices. The pwrseq librares always need to allocate extra instance for compatible string match. pwrseq_generic is intended for general purpose of power sequence, which handles gpios and clocks currently, and can cover other controls in future. The host driver just needs to call of_pwrseq_on/of_pwrseq_off if only one power sequence is needed, else call of_pwrseq_on_list /of_pwrseq_off_list instead (eg, USB hub driver). For new power sequence library, it can add its compatible string to pwrseq_of_match_table, then the pwrseq core will match it with DT's, and choose this library at runtime. Signed-off-by: Peter Chen Tested-by: Maciej S. Szmigiero Tested-by Joshua Clayton Reviewed-by: Matthias Kaehlcke Tested-by: Matthias Kaehlcke --- MAINTAINERS | 9 ++ drivers/power/Kconfig | 1 + drivers/power/Makefile| 1 + drivers/power/pwrseq/Kconfig | 21 +++ drivers/power/pwrseq/Makefile | 2 + drivers/power/pwrseq/core.c | 237 ++ drivers/power/pwrseq/pwrseq_generic.c | 183 ++ include/linux/power/pwrseq.h | 60 + 8 files changed, 514 insertions(+) create mode 100644 drivers/power/pwrseq/Kconfig create mode 100644 drivers/power/pwrseq/Makefile create mode 100644 drivers/power/pwrseq/core.c create mode 100644 drivers/power/pwrseq/pwrseq_generic.c create mode 100644 include/linux/power/pwrseq.h diff --git a/MAINTAINERS b/MAINTAINERS index 3d838cf..066b1e4 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9621,6 +9621,15 @@ F: include/linux/pm_* F: include/linux/powercap.h F: drivers/powercap/ +POWER SEQUENCE LIBRARY +M: Peter Chen +T: git git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git +L: linux...@vger.kernel.org +S: Maintained +F: Documentation/devicetree/bindings/power/pwrseq/ +F: drivers/power/pwrseq/ +F: include/linux/power/pwrseq.h/ + POWER SUPPLY CLASS/SUBSYSTEM and DRIVERS M: Sebastian Reichel L: linux...@vger.kernel.org diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig index 63454b5..c1bb046 100644 --- a/drivers/power/Kconfig +++ b/drivers/power/Kconfig @@ -1,3 +1,4 @@ source "drivers/power/avs/Kconfig" source "drivers/power/reset/Kconfig" source "drivers/power/supply/Kconfig" +source "drivers/power/pwrseq/Kconfig" diff --git a/drivers/power/Makefile b/drivers/power/Makefile index ff35c71..7db8035 100644 --- a/drivers/power/Makefile +++ b/drivers/power/Makefile @@ -1,3 +1,4 @@ obj-$(CONFIG_POWER_AVS)+= avs/ obj-$(CONFIG_POWER_RESET) += reset/ obj-$(CONFIG_POWER_SUPPLY) += supply/ +obj-$(CONFIG_POWER_SEQUENCE) += pwrseq/ diff --git a/drivers/power/pwrseq/Kconfig b/drivers/power/pwrseq/Kconfig new file mode 100644 index 000..88f5597 --- /dev/null +++ b/drivers/power/pwrseq/Kconfig @@ -0,0 +1,21 @@ +# +# Power Sequence library +# + +menuconfig POWER_SEQUENCE + bool "Power sequence control" + depends on OF + help + It is used for drivers which needs to do power sequence + (eg, turn on clock, toggle reset gpio) before the related + devices can be found by hardware, eg, USB bus. + +if POWER_SEQUENCE + +config PWRSEQ_GENERIC + bool "Generic power sequence control" + default y + help + This is the generic power sequence control library, and is + supposed to support common power sequence usage. +endif diff --git a/drivers/power/pwrseq/Makefile b/drivers/power/pwrseq/Makefile new file mode 100644 index 000..ad82389 --- /dev/null +++ b/drivers/power/pwrseq/Makefile @@ -0,0 +1,2 @@ +obj-$(CONFIG_POWER_SEQUENCE) += core.o +obj-$(CONFIG_PWRSEQ_GENERIC) += pwrseq_generic.o diff --git a/drivers/power/pwrseq/core.c b/drivers/power/pwrseq/core.c new file mode 100644 index 000..e3c1fbb --- /dev/null +++ b/drivers/power/pwrseq/core.c @@ -0,0 +1,237 @@ +/* + * core.c power sequence core file + * + * Copyright (C) 2016 Freescale Semiconductor, Inc. + * Author: Peter Chen + * + * This program is free software: you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 of + * the License as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A P
[PATCH v10 4/8] usb: core: add power sequence handling for USB devices
Some hard-wired USB devices need to do power sequence to let the
device work normally, the typical power sequence like: enable USB
PHY clock, toggle reset pin, etc. But current Linux USB driver
lacks of such code to do it, it may cause some hard-wired USB devices
works abnormal or can't be recognized by controller at all.
In this patch, it calls power sequence library APIs to finish
the power sequence events. It will do power on sequence at hub's
probe for all devices under this hub (includes root hub).
At hub_disconnect, it will do power off sequence which is at powered
on list.
Signed-off-by: Peter Chen
Tested-by Joshua Clayton
Tested-by: Maciej S. Szmigiero
Reviewed-by: Vaibhav Hiremath
---
drivers/usb/Kconfig| 1 +
drivers/usb/core/hub.c | 41 ++---
drivers/usb/core/hub.h | 1 +
3 files changed, 40 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index fbe493d..706f261 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -40,6 +40,7 @@ config USB
tristate "Support for Host-side USB"
depends on USB_ARCH_HAS_HCD
select USB_COMMON
+ select POWER_SEQUENCE
select NLS # for UTF-8 strings
---help---
Universal Serial Bus (USB) is a specification for a serial bus
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 76e80d8..991340f 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1697,6 +1698,7 @@ static void hub_disconnect(struct usb_interface *intf)
hub->error = 0;
hub_quiesce(hub, HUB_DISCONNECT);
+ of_pwrseq_off_list(&hub->pwrseq_on_list);
mutex_lock(&usb_port_peer_mutex);
/* Avoid races with recursively_mark_NOTATTACHED() */
@@ -1724,12 +1726,41 @@ static void hub_disconnect(struct usb_interface *intf)
kref_put(&hub->kref, hub_release);
}
+#ifdef CONFIG_OF
+static int hub_of_pwrseq_on(struct usb_hub *hub)
+{
+ struct device *parent;
+ struct usb_device *hdev = hub->hdev;
+ struct device_node *np;
+ int ret;
+
+ if (hdev->parent)
+ parent = &hdev->dev;
+ else
+ parent = bus_to_hcd(hdev->bus)->self.controller;
+
+ for_each_child_of_node(parent->of_node, np) {
+ ret = of_pwrseq_on_list(np, &hub->pwrseq_on_list);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+#else
+static int hub_of_pwrseq_on(struct usb_hub *hub)
+{
+ return 0;
+}
+#endif
+
static int hub_probe(struct usb_interface *intf, const struct usb_device_id
*id)
{
struct usb_host_interface *desc;
struct usb_endpoint_descriptor *endpoint;
struct usb_device *hdev;
struct usb_hub *hub;
+ int ret = -ENODEV;
desc = intf->cur_altsetting;
hdev = interface_to_usbdev(intf);
@@ -1834,6 +1865,7 @@ static int hub_probe(struct usb_interface *intf, const
struct usb_device_id *id)
INIT_DELAYED_WORK(&hub->leds, led_work);
INIT_DELAYED_WORK(&hub->init_work, NULL);
INIT_WORK(&hub->events, hub_event);
+ INIT_LIST_HEAD(&hub->pwrseq_on_list);
usb_get_intf(intf);
usb_get_dev(hdev);
@@ -1847,11 +1879,14 @@ static int hub_probe(struct usb_interface *intf, const
struct usb_device_id *id)
if (id->driver_info & HUB_QUIRK_CHECK_PORT_AUTOSUSPEND)
hub->quirk_check_port_auto_suspend = 1;
- if (hub_configure(hub, endpoint) >= 0)
- return 0;
+ if (hub_configure(hub, endpoint) >= 0) {
+ ret = hub_of_pwrseq_on(hub);
+ if (!ret)
+ return 0;
+ }
hub_disconnect(intf);
- return -ENODEV;
+ return ret;
}
static int
diff --git a/drivers/usb/core/hub.h b/drivers/usb/core/hub.h
index 34c1a7e..cd86f91 100644
--- a/drivers/usb/core/hub.h
+++ b/drivers/usb/core/hub.h
@@ -78,6 +78,7 @@ struct usb_hub {
struct delayed_work init_work;
struct work_struct events;
struct usb_port **ports;
+ struct list_headpwrseq_on_list; /* powered pwrseq node list */
};
/**
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v10 0/8] power: add power sequence library
Hi all, This is a follow-up for my last power sequence framework patch set [1]. According to Rob Herring and Ulf Hansson's comments[2]. The kinds of power sequence instances will be added at postcore_initcall, the match criteria is compatible string first, if the compatible string is not matched between dts and library, it will try to use generic power sequence. The host driver just needs to call of_pwrseq_on/of_pwrseq_off if only one power sequence instance is needed, for more power sequences are used, using of_pwrseq_on_list/of_pwrseq_off_list instead (eg, USB hub driver). In future, if there are special power sequence requirements, the special power sequence library can be created. This patch set is tested on i.mx6 sabresx evk using a dts change, I use two hot-plug devices to simulate this use case, the related binding change is updated at patch [1/6], The udoo board changes were tested using my last power sequence patch set.[3] Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also need to power on itself before it can be found by ULPI bus. [1] http://www.spinics.net/lists/linux-usb/msg142755.html [2] http://www.spinics.net/lists/linux-usb/msg143106.html [3] http://www.spinics.net/lists/linux-usb/msg142815.html Changes for v10: - Improve the kernel-doc for power sequence core, including exported APIs and main structure. [Patch 2/8] - Change Kconfig, and let the user choose power sequence. [Patch 2/8] - Delete EXPORT_SYMBOL and change related APIs as local, these APIs do not be intended to export currently. [Patch 2/8] - Selete POWER_SEQUENCE at USB core's Kconfig. [Patch 4/8] Changes for v9: - Add Vaibhav Hiremath's reviewed-by [Patch 4/8] - Rebase to v4.9-rc1 Changes for v8: - Allocate one extra pwrseq instance if pwrseq_get has succeed, it can avoid preallocate instances problem which the number of instance is decided at compile time, thanks for Heiko Stuebner's suggestion [Patch 2/8] - Delete pwrseq_compatible_sample.c which is the demo purpose to show compatible match method. [Patch 2/8] - Add Maciej S. Szmigiero's tested-by. [Patch 7/8] Changes for v7: - Create kinds of power sequence instance at postcore_initcall, and match the instance with node using compatible string, the beneit of this is the host driver doesn't need to consider which pwrseq instance needs to be used, and pwrseq core will match it, however, it eats some memories if less power sequence instances are used. [Patch 2/8] - Add pwrseq_compatible_sample.c to test match pwrseq using device_id. [Patch 2/8] - Fix the comments Vaibhav Hiremath adds for error path for clock and do not use device_node for parameters at pwrseq_on. [Patch 2/8] - Simplify the caller to use power sequence, follows Alan's commnets [Patch 4/8] - Tested three pwrseq instances together using both specific compatible string and generic libraries. Changes for v6: - Add Matthias Kaehlcke's Reviewed-by and Tested-by. (patch [2/6]) - Change chipidea core of_node assignment for coming user. (patch [5/6]) - Applies Joshua Clayton's three dts changes for two boards, the USB device's reg has only #address-cells, but without #size-cells. Changes for v5: - Delete pwrseq_register/pwrseq_unregister, which is useless currently - Fix the linker error when the pwrseq user is compiled as module Changes for v4: - Create the patch on next-20160722 - Fix the of_node is not NULL after chipidea driver is unbinded [Patch 5/6] - Using more friendly wait method for reset gpio [Patch 2/6] - Support multiple input clocks [Patch 2/6] - Add Rob Herring's ack for DT changes - Add Joshua Clayton's Tested-by Changes for v3: - Delete "power-sequence" property at binding-doc, and change related code at both library and user code. - Change binding-doc example node name with Rob's comments - of_get_named_gpio_flags only gets the gpio, but without setting gpio flags, add additional code request gpio with proper gpio flags - Add Philipp Zabel's Ack and MAINTAINER's entry Changes for v2: - Delete "pwrseq" prefix and clock-names for properties at dt binding - Should use structure not but its pointer for kzalloc - Since chipidea core has no of_node, let core's of_node equals glue layer's at core's probe Joshua Clayton (2): ARM: dts: imx6qdl: Enable usb node children with ARM: dts: imx6q-evi: Fix onboard hub reset line Peter Chen (6): binding-doc: power: pwrseq-generic: add binding doc for generic power sequence library power: add power sequence library binding-doc: usb: usb-device: add optional properties for power sequence usb: core: add power sequence handling for USB devices usb: chipidea: let chipidea core device of_node equal's glue layer device of_node ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property .../bindings/power/pwrseq/pwrseq-generic.txt | 48 + .../devicetree/bindings/usb/usb-device.txt | 10 +- MAINTAINERS| 9 +
Re: [PATCH] usb: mtu3: declare functions static
Hi,
On Sun, 2016-11-13 at 20:45 +, Sudip Mukherjee wrote:
> The only user of the functions mtu3_irq() and gpd_ring_empty() are in
> the same file. They can be declared as static.
>
> Signed-off-by: Sudip Mukherjee
> ---
> drivers/usb/mtu3/mtu3_core.c | 2 +-
> drivers/usb/mtu3/mtu3_qmu.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/mtu3/mtu3_core.c b/drivers/usb/mtu3/mtu3_core.c
> index 520e55a..603b7f84 100644
> --- a/drivers/usb/mtu3/mtu3_core.c
> +++ b/drivers/usb/mtu3/mtu3_core.c
> @@ -696,7 +696,7 @@ static irqreturn_t mtu3_u2_common_isr(struct mtu3 *mtu)
> return IRQ_HANDLED;
> }
>
> -irqreturn_t mtu3_irq(int irq, void *data)
> +static irqreturn_t mtu3_irq(int irq, void *data)
> {
> struct mtu3 *mtu = (struct mtu3 *)data;
> unsigned long flags;
> diff --git a/drivers/usb/mtu3/mtu3_qmu.c b/drivers/usb/mtu3/mtu3_qmu.c
> index a6dd292..7d9ba8a 100644
> --- a/drivers/usb/mtu3/mtu3_qmu.c
> +++ b/drivers/usb/mtu3/mtu3_qmu.c
> @@ -168,7 +168,7 @@ static struct qmu_gpd *advance_deq_gpd(struct
> mtu3_gpd_ring *ring)
> }
>
> /* check if a ring is emtpy */
> -int gpd_ring_empty(struct mtu3_gpd_ring *ring)
> +static int gpd_ring_empty(struct mtu3_gpd_ring *ring)
> {
> struct qmu_gpd *enq = ring->enqueue;
> struct qmu_gpd *next;
It's my carelessness.
Acked-by: Chunfeng Yun
Thanks
--
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 v10 7/8] ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property
The current dts describes USB HUB's property at USB controller's
entry, it is improper. The USB HUB should be the child node
under USB controller, and power sequence properties are under
it. Besides, using gpio pinctrl setting for USB2415's reset pin.
Signed-off-by: Peter Chen
Signed-off-by: Joshua Clayton
Tested-by: Maciej S. Szmigiero
---
arch/arm/boot/dts/imx6qdl-udoo.dtsi | 26 --
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-udoo.dtsi
b/arch/arm/boot/dts/imx6qdl-udoo.dtsi
index c96c91d..a173de2 100644
--- a/arch/arm/boot/dts/imx6qdl-udoo.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-udoo.dtsi
@@ -9,6 +9,8 @@
*
*/
+#include
+
/ {
aliases {
backlight = &backlight;
@@ -58,17 +60,6 @@
#address-cells = <1>;
#size-cells = <0>;
- reg_usb_h1_vbus: regulator@0 {
- compatible = "regulator-fixed";
- reg = <0>;
- regulator-name = "usb_h1_vbus";
- regulator-min-microvolt = <500>;
- regulator-max-microvolt = <500>;
- enable-active-high;
- startup-delay-us = <2>; /* USB2415 requires a POR of 1
us minimum */
- gpio = <&gpio7 12 0>;
- };
-
reg_panel: regulator@1 {
compatible = "regulator-fixed";
reg = <1>;
@@ -188,7 +179,7 @@
pinctrl_usbh: usbhgrp {
fsl,pins = <
- MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x8000
+ MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x1b0b0
MX6QDL_PAD_NANDF_CS2__CCM_CLKO2 0x130b0
>;
};
@@ -259,9 +250,16 @@
&usbh1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usbh>;
- vbus-supply = <®_usb_h1_vbus>;
- clocks = <&clks IMX6QDL_CLK_CKO>;
status = "okay";
+
+ usb2415: hub@1 {
+ compatible = "usb424,2514";
+ reg = <1>;
+
+ clocks = <&clks IMX6QDL_CLK_CKO>;
+ reset-gpios = <&gpio7 12 GPIO_ACTIVE_LOW>;
+ reset-duration-us = <3000>;
+ };
};
&usdhc3 {
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v10 8/8] ARM: dts: imx6q-evi: Fix onboard hub reset line
From: Joshua Clayton
Previously the onboard hub was made to work by treating its
reset gpio as a regulator enable.
Get rid of that kludge now that pwseq has added reset gpio support
Move pin muxing the hub reset pin into the usbh1 group
Signed-off-by: Joshua Clayton
Signed-off-by: Peter Chen
---
arch/arm/boot/dts/imx6q-evi.dts | 25 +++--
1 file changed, 7 insertions(+), 18 deletions(-)
diff --git a/arch/arm/boot/dts/imx6q-evi.dts b/arch/arm/boot/dts/imx6q-evi.dts
index 6de21ff..3277a06 100644
--- a/arch/arm/boot/dts/imx6q-evi.dts
+++ b/arch/arm/boot/dts/imx6q-evi.dts
@@ -54,18 +54,6 @@
reg = <0x1000 0x4000>;
};
- reg_usbh1_vbus: regulator-usbhubreset {
- compatible = "regulator-fixed";
- regulator-name = "usbh1_vbus";
- regulator-min-microvolt = <500>;
- regulator-max-microvolt = <500>;
- enable-active-high;
- startup-delay-us = <2>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_usbh1_hubreset>;
- gpio = <&gpio7 12 GPIO_ACTIVE_HIGH>;
- };
-
reg_usb_otg_vbus: regulator-usbotgvbus {
compatible = "regulator-fixed";
regulator-name = "usb_otg_vbus";
@@ -207,12 +195,18 @@
};
&usbh1 {
- vbus-supply = <®_usbh1_vbus>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usbh1>;
dr_mode = "host";
disable-over-current;
status = "okay";
+
+ usb2415host: hub@1 {
+ compatible = "usb424,2513";
+ reg = <1>;
+ reset-gpios = <&gpio7 12 GPIO_ACTIVE_LOW>;
+ reset-duration-us = <3000>;
+ };
};
&usbotg {
@@ -471,11 +465,6 @@
MX6QDL_PAD_GPIO_3__USB_H1_OC 0x1b0b0
/* usbh1_b OC */
MX6QDL_PAD_GPIO_0__GPIO1_IO00 0x1b0b0
- >;
- };
-
- pinctrl_usbh1_hubreset: usbh1hubresetgrp {
- fsl,pins = <
MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x1b0b0
>;
};
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v10 5/8] usb: chipidea: let chipidea core device of_node equal's glue layer device of_node
From: Peter Chen
At device tree, we have no device node for chipidea core,
the glue layer's node is the parent node for host and udc
device. But in related driver, the parent device is chipidea
core. So, in order to let the common driver get parent's node,
we let the core's device node equals glue layer device node.
Signed-off-by: Peter Chen
Tested-by: Maciej S. Szmigiero
Tested-by Joshua Clayton
---
drivers/usb/chipidea/core.c | 27 ++-
1 file changed, 22 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 69426e6..6839e19 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -927,6 +927,16 @@ static int ci_hdrc_probe(struct platform_device *pdev)
return -ENODEV;
}
+ /*
+* At device tree, we have no device node for chipidea core,
+* the glue layer's node is the parent node for host and udc
+* device. But in related driver, the parent device is chipidea
+* core. So, in order to let the common driver get parent's node,
+* we let the core's device node equals glue layer's node.
+*/
+ if (dev->parent && dev->parent->of_node)
+ dev->of_node = dev->parent->of_node;
+
if (ci->platdata->phy) {
ci->phy = ci->platdata->phy;
} else if (ci->platdata->usb_phy) {
@@ -937,11 +947,15 @@ static int ci_hdrc_probe(struct platform_device *pdev)
/* if both generic PHY and USB PHY layers aren't enabled */
if (PTR_ERR(ci->phy) == -ENOSYS &&
- PTR_ERR(ci->usb_phy) == -ENXIO)
- return -ENXIO;
+ PTR_ERR(ci->usb_phy) == -ENXIO) {
+ ret = -ENXIO;
+ goto clear_of_node;
+ }
- if (IS_ERR(ci->phy) && IS_ERR(ci->usb_phy))
- return -EPROBE_DEFER;
+ if (IS_ERR(ci->phy) && IS_ERR(ci->usb_phy)) {
+ ret = -EPROBE_DEFER;
+ goto clear_of_node;
+ }
if (IS_ERR(ci->phy))
ci->phy = NULL;
@@ -952,7 +966,7 @@ static int ci_hdrc_probe(struct platform_device *pdev)
ret = ci_usb_phy_init(ci);
if (ret) {
dev_err(dev, "unable to init phy: %d\n", ret);
- return ret;
+ goto clear_of_node;
}
ci->hw_bank.phys = res->start;
@@ -1058,6 +1072,8 @@ static int ci_hdrc_probe(struct platform_device *pdev)
ci_role_destroy(ci);
deinit_phy:
ci_usb_phy_exit(ci);
+clear_of_node:
+ dev->of_node = NULL;
return ret;
}
@@ -1076,6 +1092,7 @@ static int ci_hdrc_remove(struct platform_device *pdev)
ci_extcon_unregister(ci);
ci_role_destroy(ci);
ci_hdrc_enter_lpm(ci, true);
+ ci->dev->of_node = NULL;
ci_usb_phy_exit(ci);
return 0;
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v10 6/8] ARM: dts: imx6qdl: Enable usb node children with
From: Joshua Clayton
Give usb nodes #address and #size attributes, so that a child node
representing a permanently connected device such as an onboard hub may
be addressed with a attribute
Signed-off-by: Joshua Clayton
Signed-off-by: Peter Chen
---
arch/arm/boot/dts/imx6qdl.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index b13b0b2..8fc66e1 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -935,6 +935,8 @@
usbh1: usb@02184200 {
compatible = "fsl,imx6q-usb", "fsl,imx27-usb";
+ #address-cells = <1>;
+ #size-cells = <0>;
reg = <0x02184200 0x200>;
interrupts = <0 40 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6QDL_CLK_USBOH3>;
@@ -949,6 +951,8 @@
usbh2: usb@02184400 {
compatible = "fsl,imx6q-usb", "fsl,imx27-usb";
+ #address-cells = <1>;
+ #size-cells = <0>;
reg = <0x02184400 0x200>;
interrupts = <0 41 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6QDL_CLK_USBOH3>;
@@ -962,6 +966,8 @@
usbh3: usb@02184600 {
compatible = "fsl,imx6q-usb", "fsl,imx27-usb";
+ #address-cells = <1>;
+ #size-cells = <0>;
reg = <0x02184600 0x200>;
interrupts = <0 42 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6QDL_CLK_USBOH3>;
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 5/6] usb: dwc3: use bus->sysdev for DMA configuration
On Fri, Nov 11, 2016 at 09:31:09PM +0100, Arnd Bergmann wrote:
> On Thursday, November 10, 2016 1:02:11 PM CET Felipe Balbi wrote:
> > > @@ -123,8 +119,8 @@ int dwc3_host_init(struct dwc3 *dwc)
> > > void dwc3_host_exit(struct dwc3 *dwc)
> > > {
> > > phy_remove_lookup(dwc->usb2_generic_phy, "usb2-phy",
> > > - dev_name(&dwc->xhci->dev));
> > > + dev_name(dwc->dev));
> > > phy_remove_lookup(dwc->usb3_generic_phy, "usb3-phy",
> > > - dev_name(&dwc->xhci->dev));
> > > + dev_name(dwc->dev));
> >
> > this looks unrelated to $subject. Care to explain?
>
> bus->sysdev is used for retrieving any information that comes from
> the platform (DT or otherwise), and the phy lookup in has to be done
> through sysdev as well because the platform cannot add it to
> the child device it has no knowledge of.
>
> When we set the sysdev to the parent, the phy lookup has to be
> added to that device as well, rather than the child device.
>
Then, the device should change to dwc->sysdev, and phy_create_lookup
in this file needs to change too.
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v12 0/9] usbip: exporting devices
Hello, > What do you mean by "exporting"? You never really explain that, so again, > I don't understand why this patchset is needed :( I wrote in the cover letter but it might be hart to catch. I will try to improve in the next version. 1) The meaning Please, check original Linux/tools/usb/usbip/src/usbip_network.h: L.87 saying "Export a USB device to a remote host." 2) The reasons 2-1) Gives flexibility of connecting direction Using USB/IP in internet, there may be two cases. a) an application is inside firewall and devices are outside. b) devices are inside firewall and an application is inside. In case-a, import works because the connection is from inside. In case-b, import doesn't works because the connection is from outside. In case-b, connection from device side is needed. 2-2) Usability of operations When two Linux machines are in small distance, bind (makes importable) at device side and attach (import) at application side is OK. If application is as cloud service or in blade server connect (export) from device side is useful. There's a security issue in the cover letter but it's only when application side daemon is stared. When it's not started, it doesn't affect old usage. NOTE: This patch set touches only tools/usb/usbip, doesn't touch drivers. Direction of URBs is not changed, only direction of connecting and disconnecting in userspace are added. Best Regards, nobuo.iwata // > -Original Message- > From: linux-usb-ow...@vger.kernel.org > [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Greg KH > Sent: Thursday, November 10, 2016 9:06 PM > To: fx IWATA NOBUO > Cc: valentina.mane...@gmail.com; shuah...@samsung.com; > linux-usb@vger.kernel.org; fx MICHIMURA TADAO > Subject: Re: [PATCH v12 0/9] usbip: exporting devices > > On Thu, Oct 13, 2016 at 12:52:04PM +0900, Nobuo Iwata wrote: > > Dear all, > > > > This series of patches adds exporting device operation to USB/IP. > > What do you mean by "exporting"? You never really explain that, so again, > I don't understand why this patchset is needed :( > > 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 -- 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 v10 3/8] binding-doc: usb: usb-device: add optional properties for power sequence
Add optional properties for power sequence.
Signed-off-by: Peter Chen
Acked-by: Rob Herring
---
Documentation/devicetree/bindings/usb/usb-device.txt | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/usb/usb-device.txt
b/Documentation/devicetree/bindings/usb/usb-device.txt
index 1c35e7b..3661dd2 100644
--- a/Documentation/devicetree/bindings/usb/usb-device.txt
+++ b/Documentation/devicetree/bindings/usb/usb-device.txt
@@ -13,6 +13,10 @@ Required properties:
- reg: the port number which this device is connecting to, the range
is 1-31.
+Optional properties:
+power sequence properties, see
+Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt for detail
+
Example:
&usb1 {
@@ -21,8 +25,12 @@ Example:
#address-cells = <1>;
#size-cells = <0>;
- hub: genesys@1 {
+ genesys: hub@1 {
compatible = "usb5e3,608";
reg = <1>;
+
+ clocks = <&clks IMX6SX_CLK_CKO>;
+ reset-gpios = <&gpio4 5 GPIO_ACTIVE_LOW>; /* hub reset pin */
+ reset-duration-us = <10>;
};
}
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] USB: chipidea fixes for v4.9
The following changes since commit 18266403f3fe507f0246faa1d5432333a2f139ca: USB: cdc-acm: fix TIOCMIWAIT (2016-11-10 13:12:59 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git/ tags/usb-ci-v4.9-rc6 for you to fetch changes up to 62ee9585fed19e4de9c3941b9c74044205ae13bd: usb: chipidea: move the lock initialization to core file (2016-11-14 09:42:25 +0800) One patch to fix kernel dump for non-initialized lock Peter Chen (1): usb: chipidea: move the lock initialization to core file drivers/usb/chipidea/core.c | 1 + drivers/usb/chipidea/udc.c | 2 -- 2 files changed, 1 insertion(+), 2 deletions(-) -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v6 2/2] usbip: vhci extension: dynamic extension
> There is no patch 1/3 in this series, it's only a 2 patch series! Sorry. The 1/3 had been merged at 4.9-rc1. I will fix the change log. > Please fix this up, and put a lot of the text in your 0/2 cover > letter in these 2 patches so that we know what is going on with them. OK. Thank you, nobuo.iwata // > -Original Message- > From: Greg KH [mailto:gre...@linuxfoundation.org] > Sent: Thursday, November 10, 2016 9:05 PM > To: fx IWATA NOBUO > Cc: valentina.mane...@gmail.com; shuah...@samsung.com; > linux-usb@vger.kernel.org; fx MICHIMURA TADAO > Subject: Re: [PATCH v6 2/2] usbip: vhci extension: dynamic extension > > On Fri, Sep 30, 2016 at 02:41:54PM +0900, Nobuo Iwata wrote: > > Modification for dynamic device registration and unregistration. > > > > 1. kernel config > > > > Followings are added. > > > > USBIP_VHCI_HC_PORTS: Number of ports per USB/IP virtual host > > controller. The default is 8 - same as current VHCI_NPORTS. > > USBIP_VHCI_MAX_HCS: Muximum number of USB/IP virtual host controllers. > > The default is 1. > > USBIP_VHCI_INIT_HCS: Initial number of USB/IP virtual host controllers. > > The default is 1. > > Static number of devices: USBIP_VHCI_NR_HCS in patch 1/3 is removed > > with this patch. > > There is no patch 1/3 in this series, it's only a 2 patch series! > > I am totally confused now. Please fix this up, and put a lot of the text > in your 0/2 cover letter in these 2 patches so that we know what is going > on with them. I think I do, but based on this line, I don't think so > anymore :( > > 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 v12 1/9] usbip: exporting devices: modifications to network header
> Documentation should be a last patch, as you really are not implementing > these network changes in this patch :( I will fix it. Thank you, nobuo.iwata // > -Original Message- > From: Greg KH [mailto:gre...@linuxfoundation.org] > Sent: Thursday, November 10, 2016 9:08 PM > To: fx IWATA NOBUO > Cc: valentina.mane...@gmail.com; shuah...@samsung.com; > linux-usb@vger.kernel.org; fx MICHIMURA TADAO > Subject: Re: [PATCH v12 1/9] usbip: exporting devices: modifications to > network header > > On Thu, Oct 13, 2016 at 12:52:05PM +0900, Nobuo Iwata wrote: > > Modification to export and un-export response in > > tools/usb/usbip/src/usbip_network.h. It just changes return code type > > from int to uint32_t as same as other responses. > > > > Added export and un-export request/response to > > Documentation/usb/usbip_protocol.txt. > > > > Signed-off-by: Nobuo Iwata > > --- > > Documentation/usb/usbip_protocol.txt | 204 > > --- > > Documentation should be a last patch, as you really are not implementing > these network changes in this patch :( -- 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 v12 2/9] usbip: exporting devices: modifications to host side libraries
> Minor nit, you are not modifying this file enough to claim copyright,
> according to the copyright rules I am familiar with, so please do not do
> so here.
> Same here :(
I will fix them.
nobuo.iwata
//
> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Thursday, November 10, 2016 9:09 PM
> To: fx IWATA NOBUO
> Cc: valentina.mane...@gmail.com; shuah...@samsung.com;
> linux-usb@vger.kernel.org; fx MICHIMURA TADAO
> Subject: Re: [PATCH v12 2/9] usbip: exporting devices: modifications to
> host side libraries
>
> On Thu, Oct 13, 2016 at 12:52:06PM +0900, Nobuo Iwata wrote:
> > usbip_get_device() method in usbip_host_driver_ops was not used. It is
> > modified as a function to find an exported device for new operations
> > 'connect' and 'disconnect'.
> >
> > bind and unbind function are exported for the new operations.
> >
> > Signed-off-by: Nobuo Iwata
> > ---
> > tools/usb/usbip/libsrc/usbip_host_common.c | 6 ++
> > tools/usb/usbip/libsrc/usbip_host_common.h | 8
> > tools/usb/usbip/src/usbip.h| 3 +++
> > tools/usb/usbip/src/usbip_bind.c | 7 ---
> > tools/usb/usbip/src/usbip_unbind.c | 7 ---
> > 5 files changed, 17 insertions(+), 14 deletions(-)
> >
> > diff --git a/tools/usb/usbip/libsrc/usbip_host_common.c
> > b/tools/usb/usbip/libsrc/usbip_host_common.c
> > index 9d41522..6a98d6c 100644
> > --- a/tools/usb/usbip/libsrc/usbip_host_common.c
> > +++ b/tools/usb/usbip/libsrc/usbip_host_common.c
> > @@ -256,17 +256,15 @@ int usbip_export_device(struct
> > usbip_exported_device *edev, int sockfd) }
> >
> > struct usbip_exported_device *usbip_generic_get_device(
> > - struct usbip_host_driver *hdriver, int num)
> > + struct usbip_host_driver *hdriver, char *busid)
> > {
> > struct list_head *i;
> > struct usbip_exported_device *edev;
> > - int cnt = 0;
> >
> > list_for_each(i, &hdriver->edev_list) {
> > edev = list_entry(i, struct usbip_exported_device, node);
> > - if (num == cnt)
> > + if (!strncmp(busid, edev->udev.busid,
> SYSFS_BUS_ID_SIZE))
> > return edev;
> > - cnt++;
> > }
> >
> > return NULL;
> > diff --git a/tools/usb/usbip/libsrc/usbip_host_common.h
> > b/tools/usb/usbip/libsrc/usbip_host_common.h
> > index a64b803..f9a9def 100644
> > --- a/tools/usb/usbip/libsrc/usbip_host_common.h
> > +++ b/tools/usb/usbip/libsrc/usbip_host_common.h
> > @@ -38,7 +38,7 @@ struct usbip_host_driver_ops {
> > void (*close)(struct usbip_host_driver *hdriver);
> > int (*refresh_device_list)(struct usbip_host_driver *hdriver);
> > struct usbip_exported_device * (*get_device)(
> > - struct usbip_host_driver *hdriver, int num);
> > + struct usbip_host_driver *hdriver, char *busid);
> >
> > int (*read_device)(struct udev_device *sdev,
> >struct usbip_usb_device *dev);
> > @@ -86,11 +86,11 @@ static inline int usbip_refresh_device_list(struct
> > usbip_host_driver *hdriver) }
> >
> > static inline struct usbip_exported_device * -usbip_get_device(struct
> > usbip_host_driver *hdriver, int num)
> > +usbip_get_device(struct usbip_host_driver *hdriver, char *busid)
> > {
> > if (!hdriver->ops.get_device)
> > return NULL;
> > - return hdriver->ops.get_device(hdriver, num);
> > + return hdriver->ops.get_device(hdriver, busid);
> > }
> >
> > /* Helper functions for implementing driver backend */ @@ -99,6 +99,6
> > @@ void usbip_generic_driver_close(struct usbip_host_driver *hdriver);
> > int usbip_generic_refresh_device_list(struct usbip_host_driver
> > *hdriver); int usbip_export_device(struct usbip_exported_device
> > *edev, int sockfd); struct usbip_exported_device
> *usbip_generic_get_device(
> > - struct usbip_host_driver *hdriver, int num);
> > + struct usbip_host_driver *hdriver, char *busid);
> >
> > #endif /* __USBIP_HOST_COMMON_H */
> > diff --git a/tools/usb/usbip/src/usbip.h b/tools/usb/usbip/src/usbip.h
> > index 84fe66a..c296910 100644
> > --- a/tools/usb/usbip/src/usbip.h
> > +++ b/tools/usb/usbip/src/usbip.h
> > @@ -37,4 +37,7 @@ void usbip_list_usage(void); void
> > usbip_bind_usage(void); void usbip_unbind_usage(void);
> >
> > +int usbip_bind_device(char *busid);
> > +int usbip_unbind_device(char *busid);
> > +
> > #endif /* __USBIP_H */
> > diff --git a/tools/usb/usbip/src/usbip_bind.c
> > b/tools/usb/usbip/src/usbip_bind.c
> > index fa46141..1c09338 100644
> > --- a/tools/usb/usbip/src/usbip_bind.c
> > +++ b/tools/usb/usbip/src/usbip_bind.c
> > @@ -1,5 +1,6 @@
> > /*
> > - * Copyright (C) 2011 matt mooney
> > + * Copyright (C) 2015 Nobuo Iwata
> > + * 2011 matt mooney
>
> Minor nit, you are not modifying this file enough to claim copyright,
> according to the copyright rules I am familiar with, so please do not do
> so here.
>
> > * 2005-2007 Takahiro Hirofuchi
>
RE: [PATCH v12 4/9] usbip: exporting devices: new disconnect operation
> We need a lot more text here than just this, as it does not explain why
> this patch is needed at all :(
I will add text in next version.
Thank you,
nobuo.iwata
//
> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Thursday, November 10, 2016 9:10 PM
> To: fx IWATA NOBUO
> Cc: valentina.mane...@gmail.com; shuah...@samsung.com;
> linux-usb@vger.kernel.org; fx MICHIMURA TADAO
> Subject: Re: [PATCH v12 4/9] usbip: exporting devices: new disconnect
> operation
>
> On Thu, Oct 13, 2016 at 12:52:08PM +0900, Nobuo Iwata wrote:
> > New disconnect operation.
>
> We need a lot more text here than just this, as it does not explain why
> this patch is needed at all :(
>
> >
> > Signed-off-by: Nobuo Iwata
> > ---
> > tools/usb/usbip/src/Makefile.am| 2 +-
> > tools/usb/usbip/src/usbip.c| 6 +
> > tools/usb/usbip/src/usbip.h| 2 +
> > tools/usb/usbip/src/usbip_disconnect.c | 215
> > +
> > 4 files changed, 224 insertions(+), 1 deletion(-)
> >
> > diff --git a/tools/usb/usbip/src/Makefile.am
> > b/tools/usb/usbip/src/Makefile.am index 0947476..42760c3 100644
> > --- a/tools/usb/usbip/src/Makefile.am
> > +++ b/tools/usb/usbip/src/Makefile.am
> > @@ -7,6 +7,6 @@ sbin_PROGRAMS := usbip usbipd usbip_SOURCES :=
> > usbip.h utils.h usbip.c utils.c usbip_network.c \
> > usbip_attach.c usbip_detach.c usbip_list.c \
> > usbip_bind.c usbip_unbind.c usbip_port.c \
> > -usbip_connect.c
> > +usbip_connect.c usbip_disconnect.c
> >
> > usbipd_SOURCES := usbip_network.h usbipd.c usbip_network.c diff --git
> > a/tools/usb/usbip/src/usbip.c b/tools/usb/usbip/src/usbip.c index
> > 584d7d5..f0e9e06 100644
> > --- a/tools/usb/usbip/src/usbip.c
> > +++ b/tools/usb/usbip/src/usbip.c
> > @@ -83,6 +83,12 @@ static const struct command cmds[] = {
> > .usage = usbip_connect_usage
> > },
> > {
> > + .name = "disconnect",
> > + .fn= usbip_disconnect,
> > + .help = "Disconnect a USB device from a remote computer",
> > + .usage = usbip_disconnect_usage
> > + },
> > + {
> > .name = "list",
> > .fn= usbip_list,
> > .help = "List exportable or local USB devices", diff --git
> > a/tools/usb/usbip/src/usbip.h b/tools/usb/usbip/src/usbip.h index
> > f365353..a8cbd16 100644
> > --- a/tools/usb/usbip/src/usbip.h
> > +++ b/tools/usb/usbip/src/usbip.h
> > @@ -32,6 +32,7 @@ int usbip_bind(int argc, char *argv[]); int
> > usbip_unbind(int argc, char *argv[]); int usbip_port_show(int argc,
> > char *argv[]); int usbip_connect(int argc, char *argv[]);
> > +int usbip_disconnect(int argc, char *argv[]);
> >
> > void usbip_attach_usage(void);
> > void usbip_detach_usage(void);
> > @@ -39,6 +40,7 @@ void usbip_list_usage(void); void
> > usbip_bind_usage(void); void usbip_unbind_usage(void); void
> > usbip_connect_usage(void);
> > +void usbip_disconnect_usage(void);
> >
> > int usbip_bind_device(char *busid);
> > int usbip_unbind_device(char *busid); diff --git
> > a/tools/usb/usbip/src/usbip_disconnect.c
> > b/tools/usb/usbip/src/usbip_disconnect.c
> > new file mode 100644
> > index 000..8155384
> > --- /dev/null
> > +++ b/tools/usb/usbip/src/usbip_disconnect.c
> > @@ -0,0 +1,215 @@
> > +/*
> > + * Copyright (C) 2015 Nobuo Iwata
> > + * 2011 matt mooney
> > + * 2005-2007 Takahiro Hirofuchi
>
> How can others have copyright on a brand new file? Is it based on their
> work? If so, please write that.
>
> > + * This program is free software: you can redistribute it and/or
> > + modify
> > + * it under the terms of the GNU General Public License as published
> > + by
> > + * the Free Software Foundation, either version 2 of the License, or
> > + * (at your option) any later version.
>
> Are you sure you mean "any later version"?
>
> 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 v12 3/9] usbip: exporting devices: new connect operation
> Again, we need more text. I will add text in next version. Thank you, nobuo.iwata // > -Original Message- > From: linux-usb-ow...@vger.kernel.org > [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Greg KH > Sent: Thursday, November 10, 2016 9:12 PM > To: fx IWATA NOBUO > Cc: valentina.mane...@gmail.com; shuah...@samsung.com; > linux-usb@vger.kernel.org; fx MICHIMURA TADAO > Subject: Re: [PATCH v12 3/9] usbip: exporting devices: new connect operation > > On Thu, Oct 13, 2016 at 12:52:07PM +0900, Nobuo Iwata wrote: > > New connect operation. > > Again, we need more text. > -- > 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 v18 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
On Thu, Nov 10 2016, Baolin Wang wrote: > Hi > > On 8 November 2016 at 04:36, NeilBrown wrote: >> On Mon, Nov 07 2016, Baolin Wang wrote: >> >>> On 3 November 2016 at 09:25, NeilBrown wrote: On Tue, Nov 01 2016, Baolin Wang wrote: >>> >>> I agree with your most opinions, but these are optimization. >> >> I see them as bug fixes, not optimizations. >> >>> Firstly I >>> think we should upstream the USB charger driver. >> >> I think you missed the point. The point is that we don't *need* your >> "USB charger driver" because all the infrastructure we need is *already* >> present in the kernel. It is buggy and not used uniformly, and could >> usefully be polished and improved. But the structure is already >> present. >> >> If everyone just added new infrastructure when they didn't like, or >> didn't understand, what was already present, the kernel would become >> like the Mad Hatter's tea party, full of dirty dishes. >> >>> What I want to ask is >>> how can we notify power driver if we don't set the >>> usb_register_notifier(), then I think you give the answer is: power >>> driver can register by 'struct usb_phy->notifier'. But why usb phy >>> should notify the power driver how much current should be drawn, and I >>> still think we should notify the current in usb charger driver which >>> is better, and do not need to notify current for power driver in usb >>> phy driver. >> >> I accept that it isn't clear that the phy *should* be involved in >> communicating the negotiated power availability, but nor is it clear >> that it shouldn't. The power does travel through the physical >> interface, so physically it plays a role. >> >> But more importantly, it already *does* get told (in some cases). >> There is an interface "usb_phy_set_power()" which exists explicitly to >> tell the phy what power has been negotiated. Given that infrastructure >> exists and works, it make sense to use it. >> >> If you think it is a broken design and should be removed, then fine: >> make a case for that. Examine the history. Make sure you know why it >> is there (or make sure that information cannot be found), and then >> present a case as to why it should be removed and replaced with >> something else. But don't just leave it there and pretend it doesn't >> exist and create something similar-but-different and hope people will >> know why yours is better. That way lies madness. > > Like Peter said, it is not only PHY can detect the USB charger type, > which means there are other places can detect the charger type. If I understand Peter's example correctly, it shows a configuration where the USB PHysical interface is partly implemented in the SOC and partly in the PMIC. I appreciate that would make it more challenging to implement a PHY driver, but there is no reason it should impact anything outside of the PHY. > Second, some controller need to detect the charger type manually which > USB phy did not support. "manually" is an odd term to use in this context. I think you mean that to detect the charger type you need to issue some command to the hardware and wait for it to respond, then assess the response. That isn't at all surprising. The charger type is detected by measuring resistance between ID and GND, which may require setting up a potential and activating ADCs to measure the voltage. This can all be done internally to the phy driver. Sometimes it is easy (I did https://lkml.org/lkml/2015/2/23/746 for twl4030, though it never got upstream). The code for the imx7d does look more complex, but not intrinsically different. > Third, it did not handle what current should > be drawn in USB phy. The standards define that. The extcon just reports the cable type. Certainly it would be sensible to provide a library function to translate from cable type to current range. You don't need a new subsystem to do that, just a library function. > Fourth, we need integrate all charger plugin/out > event in one framework, not from extcon, maybe type-c in future. Why not extcon? Given that a charger is connected by an external connector, extcon seems like exactly the right thing to use. Obviously extcon doesn't report the current that was negotiated, but that is best kept separate. The battery charger can be advised of the available current either via extcon or separately via the usb subsystem. Don't conflate the two. > In a > word, we need one standard integration of this feature we need, though > like you said we should do some clean up or fix to make it better. But really, I'm not the person you need to convince. I'm just a vaguely interested bystander who is rapidly losing interest. You need to convince a maintainer, but they have so far shown remarkably little interest. I don't know why, but I'd guess that reviewing a complex new subsystem isn't much fun. Reviewing and applying clear bugfixes and i
RE: [PATCH v12 5/9] usbip: exporting devices: modifications to daemon
> > Refactoring to the daemon. > > why? Refactoring to the daemon to reuse common portion for new application side daemon. It's divided into two portion. usbipd.c : common code for both device and application side daemon. usbipd_dev.c : device-side specific code extracted from usbipd.c. --- I will write this and add explanation what's the new application side daemon using copy of cover letter diagram in next version. Thank you, nobuo.iwata // > -Original Message- > From: linux-usb-ow...@vger.kernel.org > [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Greg KH > Sent: Thursday, November 10, 2016 9:11 PM > To: fx IWATA NOBUO > Cc: valentina.mane...@gmail.com; shuah...@samsung.com; > linux-usb@vger.kernel.org; fx MICHIMURA TADAO > Subject: Re: [PATCH v12 5/9] usbip: exporting devices: modifications to > daemon > > On Thu, Oct 13, 2016 at 12:52:09PM +0900, Nobuo Iwata wrote: > > Refactoring to the daemon. > > why? > > -- > 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 0/2] Two cpp41 pm runtime found when testing with usb
On Wed, Nov 09, 2016 at 09:47:57AM -0700, Tony Lindgren wrote: > Hi, > > I found two pm runtime issues when testing with usb on beaglebone. > > In the am335x case cppi41 and two instances of musb controller share > the same interconnect wrapper module, so any pm issues with musb or > cppi41 will keep the interconnect wrapper module busy. Applied both. And as I have told you previously please use the correct subsystem tag. I have fixed them again! -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] drivers: usb: phy: Add qoriq usb 3.0 phy driver support
Adds qoriq usb 3.0 phy driver support for LS1043A platform. Describes the qoriq usb 2.0 phy driver binding, currently used for LS1043A platform. Adds entries in dts to enable USB 3.0 phy driver. Sriram Dash (2): drivers: usb: phy: Add qoriq usb 3.0 phy driver support arm64: dts: ls1043a: Enable USB 3.0 phy driver .../devicetree/bindings/phy/phy-qoriq-usb3.txt | 38 arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 33 drivers/phy/Kconfig| 8 + drivers/phy/Makefile | 1 + drivers/phy/phy-qoriq-usb3.c | 202 + 5 files changed, 282 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt create mode 100644 drivers/phy/phy-qoriq-usb3.c -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] arm64: dts: ls1043a: Enable USB 3.0 phy driver
This patch adds entries in dts to enable USB 3.0 PHY driver.
Signed-off-by: Sriram Dash
---
arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 33 ++
1 file changed, 33 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index 97d331e..c87fc16 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -475,11 +475,40 @@
<&clockgen 4 0>;
};
+ usbphy0: usb3-phy@084f {
+ compatible = "fsl,qoriq-usb3-phy";
+ reg = <0x0 0x01570070 0x0 0xC>,
+ <0x0 0x084F 0x0 0x5000>;
+ reg-names = "param_ctrl", "phy_base";
+ #phy-cells = <0>;
+ phy_type = "utmi";
+ };
+
+ usbphy1: usb3-phy@0850 {
+ compatible = "fsl,qoriq-usb3-phy";
+ reg = <0x0 0x0157007C 0x0 0xC>,
+ <0x0 0x0850 0x0 0x5000>;
+ reg-names = "param_ctrl", "phy_base";
+ #phy-cells = <0>;
+ phy_type = "utmi";
+ };
+
+ usbphy2: usb3-phy@0851 {
+ compatible = "fsl,qoriq-usb3-phy";
+ reg = <0x0 0x01570088 0x0 0xC>,
+ <0x0 0x0851 0x0 0x5000>;
+ reg-names = "param_ctrl", "phy_base";
+ #phy-cells = <0>;
+ phy_type = "utmi";
+ };
+
usb0: usb3@2f0 {
compatible = "snps,dwc3";
reg = <0x0 0x2f0 0x0 0x1>;
interrupts = <0 60 0x4>;
dr_mode = "host";
+ phys = <&usbphy0>;
+ phy-names = "usb3-phy";
snps,quirk-frame-length-adjustment = <0x20>;
snps,dis_rxdet_inp3_quirk;
};
@@ -489,6 +518,8 @@
reg = <0x0 0x300 0x0 0x1>;
interrupts = <0 61 0x4>;
dr_mode = "host";
+ phys = <&usbphy1>;
+ phy-names = "usb3-phy";
snps,quirk-frame-length-adjustment = <0x20>;
snps,dis_rxdet_inp3_quirk;
};
@@ -498,6 +529,8 @@
reg = <0x0 0x310 0x0 0x1>;
interrupts = <0 63 0x4>;
dr_mode = "host";
+ phys = <&usbphy2>;
+ phy-names = "usb3-phy";
snps,quirk-frame-length-adjustment = <0x20>;
snps,dis_rxdet_inp3_quirk;
};
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V12 1/1] usb:serial: Add Fintek F81532/534 driver
This driver is for Fintek F81532/F81534 USB to Serial Ports IC. F81532 spec: https://drive.google.com/file/d/0B8vRwwYO7aMFOTRRMmhWQVNvajQ/view?usp= sharing F81534 spec: https://drive.google.com/file/d/0B8vRwwYO7aMFV29pQWJqbVBNc00/view?usp= sharing Features: 1. F81532 is 1-to-2 & F81534 is 1-to-4 serial ports IC 2. Support Baudrate from B50 to B115200. Signed-off-by: Ji-Ze Hong (Peter Hong) --- Changelog: V12 1. Max TX change from 100 to 124 bytes. 2. Add probe() to verify endpoints & packet size. 3. Rename function names. set/get_normal_register() -> set/get_register() set/get_register() -> set/get_port_register() set/get_register_delay() -> set/get_spi_register() read_data() -> read_flash() command_delay() -> wait_for_spi() V11 1. Reduce F81534_MAX_BUS_RETRY from 2000 to 20. We are only using internal SPI bus to read flash when attach() & calc_num_ports() and never read flash when the F81532/534 in full loading, so we can reduce retry count. 2. Modify attach() & calc_num_ports() read default value only when can't find the custom setting. 3. Change tx_empty protect method from spinlock to set_bit()/ clear_bit()/test_and_clear_bit(). 4. Move calculate tty_idx[i] from port_probe() to attach(). 5. Add f81534_tx_empty() V10 1. Change the submit/kill timming for read URBs, submit when first serial port open and kill when final port close. 2. Remove all source code about controlling GPIOs. 3. Change the f81534_tiocmget() from reading shadow MSR with delay 20ms to read MSR register directly. 4. Using tty_port_initialized() to check port opened/closed. 5. Add sanity check for variables. v9 1. Remove lots of code to make more generic for F81532/534. e.g., high baud rate support, RS485/422 mode switch, most of GPIO control and internal storage write functional. 2. Change f81534_tiocmget() MSR delay from schedule_timeout_killable() to wait_for_completion_killable_timeout(). This IC will delayed receiving MSR change when doing loop-back test e.g., BurnInTest. We'll reset completion "msr_done" in f81534_update_mctrl(). If we changed MCR, the next f81534_tiocmget() will delay for 20ms or continue with new MSR arrived. 3. Fix for non-zero buffer allocated in f81534_setup_ports(). It'll make device malfunctional with incorrect tx length for other ports. v8 1. Remove driver mode GPIOLIB & RS485 control support, the driver will only load GPIO/UART Mode when driver attach() & port_probe(). 2. Add more documents for 3 generation IC with f81534_calc_num_ports(). 3. Simplify the GPIO register structure "f81534_pin_control". 4. Change all counter type from int to size_t. 5. Change some failed message with failed: "status code" and remove all exclamation mark in messages. 6. Change all save blocks to block0 due to the driver is only used 1 block (block0) to save data. 7. Change read MSR in open() instead of port_probe(). 8. use GFP_ATOMIC kmalloc mode in write(). 9. Maintain old style with 1 read URBs and 4 write URBs like mxuports.c I had tested with submit 4 read URBs, but it'll make some port freeze when doing BurnInTest Port test. v7 1. Make all gpiolib function with #ifdef CONFIG_GPIOLIB marco block. Due to F81532/534 could run without gpiolib, we implements f81534_prepare_gpio()/f81534_release_gpio() always success without CONFIG_GPIOLIB. 2. Fix crash when receiving MSR change on driver load/unload. It's cause by f81534_process_read_urb() get read URB callback data, but port private data is not init complete or released. We solve with 2 modifications. 1. add null pointer check with f81534_process_read_urb(). We'll skip this report when port_priv = NULL. 2. when "one" port f81534_port_remove() is called, kill the port-0 read URB before kfree port_priv. v6 1. Re-implement the write()/resume() function. Due to this device cant be suitable with generic write(), we'll do the submit write URB when write()/received tx empty/set_termios()/resume() 2. Logic/Phy Port mapping rewrite in f81534_port_probe() & f81534_phy_to_logic_port(). 3. Introduced "Port Hide" function. Some customer use F81532 reference design for HW layout, but really use F81534 IC. We'll check F81534_PORT_CONF_DISABLE_PORT flag with in uart mode field to do port hide with port not used. It can be avoid end-user to use not layouted port. 4. The 4x3 output-only open-drain pins for F81532/534 is designed for control outer devices (with our EVB for examples, the 4 sets of pins are designed to control transceiver mode). So we decide to implement with gpiolib interface. 5. Add device vendor id with 0x2c42 v
[PATCH 1/2] drivers: usb: phy: Add qoriq usb 3.0 phy driver support
Adds qoriq usb 3.0 phy driver support for LS1043A platform.
Describes the qoriq usb 2.0 phy driver binding, currently used
for LS1043A platform.
Signed-off-by: Sriram Dash
---
.../devicetree/bindings/phy/phy-qoriq-usb3.txt | 36
drivers/phy/Kconfig| 8 +
drivers/phy/Makefile | 1 +
drivers/phy/phy-qoriq-usb3.c | 202 +
4 files changed, 247 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
create mode 100644 drivers/phy/phy-qoriq-usb3.c
diff --git a/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
b/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
new file mode 100644
index 000..d934c80
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
@@ -0,0 +1,36 @@
+Driver for Freescale USB 3.0 PHY
+
+Required properties:
+
+- compatible : fsl,qoriq-usb3-phy
+- reg :register mappings for Parameter Configuration Register
+ and Phy base offset.
+- reg-names : "param_ctrl" and "phy_base"
+- phy_type : For multi port host USB controllers, should be one of
+ "ulpi", or "serial". For dual role USB controllers,
+ should be one of "ulpi", "utmi", "utmi_wide", or "serial".
+
+Example:
+ usbphy0: usb3-phy@084F {
+compatible = "fsl,qoriq-usb3-phy";
+reg = <0x0 0x01570070 0x0 0xC>, <0x0 0x084F 0x0
0x5000>;
+reg-names = "param_ctrl", "phy_base";
+#phy-cells = <0>;
+phy_type = "utmi";
+};
+
+usbphy1: usb3-phy@0850 {
+compatible = "fsl,qoriq-usb3-phy";
+reg = <0x0 0x0157007C 0x0 0xC>, <0x0 0x0850 0x0
0x5000>;
+reg-names = "param_ctrl", "phy_base";
+#phy-cells = <0>;
+phy_type = "utmi";
+};
+
+usbphy2: usb3-phy@0851 {
+compatible = "fsl,qoriq-usb3-phy";
+reg = <0x0 0x01570088 0x0 0xC>, <0x0 0x0851 0x0
0x5000>;
+reg-names = "param_ctrl", "phy_base";
+#phy-cells = <0>;
+phy_type = "utmi";
+};
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index fe00f91..4caa91c 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -489,4 +489,12 @@ config PHY_NS2_PCIE
help
Enable this to support the Broadcom Northstar2 PCIe PHY.
If unsure, say N.
+
+config PHY_QORIQ_USB3
+ tristate "Freescale QorIQ USB 3.0 PHY driver"
+ depends on ARCH_LAYERSCAPE
+ depends on OF
+ select GENERIC_PHY
+ help
+ Enable this to support the USB3.0 PHY on the QorIQ SoC.
endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index a534cf5..a47ee36b 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -60,3 +60,4 @@ obj-$(CONFIG_PHY_PISTACHIO_USB) +=
phy-pistachio-usb.o
obj-$(CONFIG_PHY_CYGNUS_PCIE) += phy-bcm-cygnus-pcie.o
obj-$(CONFIG_ARCH_TEGRA) += tegra/
obj-$(CONFIG_PHY_NS2_PCIE) += phy-bcm-ns2-pcie.o
+obj-$(CONFIG_PHY_QORIQ_USB3)+= phy-qoriq-usb3.o
diff --git a/drivers/phy/phy-qoriq-usb3.c b/drivers/phy/phy-qoriq-usb3.c
new file mode 100644
index 000..5255089
--- /dev/null
+++ b/drivers/phy/phy-qoriq-usb3.c
@@ -0,0 +1,202 @@
+/*
+ * Freescale QorIQ USB3 phy driver
+ *
+ * Copyright 2016 Freescale Semiconductor, Inc.
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Author: Sriram Dash
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+
+/* Parameter control */
+#define USB3PRM1CR 0x000
+#define USB3PRM1CR_VAL 0x27672b2a
+
+/*
+ * struct qoriq_usb3_phy - driver data for USB 3.0 PHY
+ * @dev: pointer to device instance of this platform device
+ * @param_ctrl: usb3 phy parameter control register base
+ * @phy_base: usb3 phy register memory base
+ * @has_erratum_flag: keeps track of erratum applicable on device
+ */
+struct qoriq_usb3_phy {
+ struct device *dev;
+ void __iomem *param_ctrl;
+ void __iomem *phy_base;
+ u32 has_erratum_flag;
+};
+
+static i
RE: [PATCH v12 6/9] usbip: exporting devices: modifications to attach and detach
> why do this refactoring? please say so why here. I will add explanation like below. --- Refactoring to attach and detach operation to reuse common portion to application(vhci)-side daemon. The new application(vhci)-side daemon executes same procedures as attach and detach. Most of common code to access vhci had been implemented in VHCI userspace wrapper(libsrc/vhci_driver.c) but left in attach and detach. With this patch, an accessor of vhci driver and tracking of vhci connections in attach and detach are moved to the VHCI userspace wrapper. --- And add what is attach, detach and application(vhci)-side daemon using a diagram. Thank you for your comment, nobuo.iwata // > -Original Message- > From: Greg KH [mailto:gre...@linuxfoundation.org] > Sent: Thursday, November 10, 2016 9:11 PM > To: fx IWATA NOBUO > Cc: valentina.mane...@gmail.com; shuah...@samsung.com; > linux-usb@vger.kernel.org; fx MICHIMURA TADAO > Subject: Re: [PATCH v12 6/9] usbip: exporting devices: modifications to > attach and detach > > On Thu, Oct 13, 2016 at 12:52:10PM +0900, Nobuo Iwata wrote: > > Refactoring to attach and detatch operation. Common parts to new > > application(vhci)-side daemon are moved to libsrc/vhci_driver.c. > > why do this refactoring? please say so why here. > > 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 net 2/2] r8152: rx descriptor check
Francois Romieu [mailto:rom...@fr.zoreil.com] > Sent: Friday, November 11, 2016 8:13 PM [...] > Invalid packet size corrupted receive descriptors in Realtek's device > reminds of CVE-2009-4537. Do you mean that the driver would get a packet exceed the size which is set to RxMaxSize? I check it with our hw engineers. They don't get any issue about RxMaxSize. And their test for RxMaxSize register is fine. > Is the silicium of both devices different enough to prevent the same > exploit to happen ? For this case, I don't think the device provide a invalid value for the receive descriptors. However, the driver sees a different value. That is why I say the memory is unbelievable. Best Regards, Hayes -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] USB hub_probe: rework ugly goto-into-compound-statement
On Sun, Nov 13, 2016 at 03:53:58PM +0300, Eugene Korenevsky wrote:
> Rework smelling code (goto inside compound statement). Perhaps this is
> legacy. Anyway such code is not appropriate for Linux kernel.
>
> Signed-off-by: Eugene Korenevsky
> ---
> Changes in v5: make `bool` a return type of `hub_check_descriptor_sanity()`
> Changes in v4: fix typo
> Changes in v3: extract the code to static function
> Changes in v2: fix spaces instead of tab, add missing 'Signed-off-by'
>
> drivers/usb/core/hub.c | 35 ++-
> 1 file changed, 18 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index cbb1467..1a316a1 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -1722,10 +1722,25 @@ static void hub_disconnect(struct usb_interface *intf)
> kref_put(&hub->kref, hub_release);
> }
>
> +static bool hub_check_descriptor_sanity(struct usb_host_interface *desc)
> +{
> + /* Some hubs have a subclass of 1, which AFAICT according to the */
> + /* specs is not defined, but it works */
> + if (desc->desc.bInterfaceSubClass != 0 &&
> + desc->desc.bInterfaceSubClass != 1)
> + return false;
> +
> + /* Multiple endpoints? What kind of mutant ninja-hub is this? */
> + if (desc->desc.bNumEndpoints != 1)
> + return false;
> +
> + /* If it's not an interrupt in endpoint, we'd better punt! */
> + return usb_endpoint_is_int_in(&desc->endpoint[0].desc) != 0;
Ok, I'm going to be really pedantic here and ask that you spell this
last statement out:
if (usb...)
return true;
return false;
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 v5] USB hub_probe: rework ugly goto-into-compound-statement
On Sun, Nov 13, 2016 at 03:53:58PM +0300, Eugene Korenevsky wrote:
> Rework smelling code (goto inside compound statement). Perhaps this is
> legacy. Anyway such code is not appropriate for Linux kernel.
>
> Signed-off-by: Eugene Korenevsky
> ---
> Changes in v5: make `bool` a return type of `hub_check_descriptor_sanity()`
> Changes in v4: fix typo
> Changes in v3: extract the code to static function
> Changes in v2: fix spaces instead of tab, add missing 'Signed-off-by'
>
> drivers/usb/core/hub.c | 35 ++-
> 1 file changed, 18 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index cbb1467..1a316a1 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -1722,10 +1722,25 @@ static void hub_disconnect(struct usb_interface *intf)
> kref_put(&hub->kref, hub_release);
> }
>
> +static bool hub_check_descriptor_sanity(struct usb_host_interface *desc)
> +{
> + /* Some hubs have a subclass of 1, which AFAICT according to the */
> + /* specs is not defined, but it works */
> + if (desc->desc.bInterfaceSubClass != 0 &&
> + desc->desc.bInterfaceSubClass != 1)
> + return false;
> +
> + /* Multiple endpoints? What kind of mutant ninja-hub is this? */
> + if (desc->desc.bNumEndpoints != 1)
> + return false;
> +
> + /* If it's not an interrupt in endpoint, we'd better punt! */
> + return usb_endpoint_is_int_in(&desc->endpoint[0].desc) != 0;
Also, the comment should say:
/* If the first endpoint is not interrupt IN, we... */
--
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 net 2/2] r8152: rx descriptor check
David Miller [mailto:da...@davemloft.net] > Sent: Monday, November 14, 2016 1:40 AM [...] > If you add this patch now, there is a much smaller likelyhood that you > will work with a high priority to figure out _why_ this is happening. > > For all we know this could be a platform bug in the DMA API for the > systems in question. > > It could also be a bug elsewhere in the driver, either in setting up > the descriptor DMA mappings or how the chip is programmed. > > Either way the true cause must be found before we start throwing > changes like this into the driver. Our hw engineer could check our device, and I could check the driver. However, for the other parts, such as the USB host controller or memory, it is difficult for me to make sure whether they are correct or not. I could only promise our devices and driver work fine. Best Regards, Hayes -- 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 net 2/2] r8152: rx descriptor check
Mark Lord [mailto:ml...@pobox.com]
> Sent: Monday, November 14, 2016 4:34 AM
[...]
> Perhaps the driver
> is somehow accessing the buffer space again after doing usb_submit_urb()?
> That would certainly produce this kind of behaviour.
I don't think so. First, the driver only read the received buffer.
That is, the driver would not change (or write) the data. Second,
The driver would lose the point address of the received buffer
after submitting the urb to the USB host controller, until the
transfer is completed by the USB host controller. That is, the
driver doesn't how to access the buffer after calling usb_submit_urb().
Best Regards,
Hayes
N�r��yb�X��ǧv�^�){.n�+{��^n�r���z���h�&�� �G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�
Re: [PATHCv10 0/2] USB Type-C Connector class
On Fri, Nov 11, 2016 at 01:04:24PM +0200, Heikki Krogerus wrote: > On Thu, Nov 10, 2016 at 01:36:09PM -0800, Guenter Roeck wrote: > > On Mon, Sep 19, 2016 at 02:16:55PM +0300, Heikki Krogerus wrote: > > > The USB Type-C class is meant to provide unified interface to the > > > userspace to present the USB Type-C ports in a system. > > > > > Any idea what is happening with this patch series ? > > > > There was no further feedback (at least as far as I know), the series > > seems to be ready to go, yet I don't see it in -next. > > I think Greg has only started to put together his usb-next branch for > this cycle. I was waiting to see if anyone else had objections about this before reviewing it myself :) I'll get to it later today... 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 00/23] xhci features for usb-next
On Fri, Nov 11, 2016 at 03:13:09PM +0200, Mathias Nyman wrote: > Hi Greg > > In addition to all the xhci cleanups, refactoring, and features for > xhci, there's a patch for usb core hub driver that changes how usb3 > devices are disabled. > > It fixes a automatic re-mount issue seen when users try to "safely remove" > or eject a usb mass storage device. I'd like to get Alan's ack on that before applying it. Also, shouldn't that go to the stable kernel trees as well? 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
PLEASE VIEW THE ATTACHED FILE AND CONTACT ME.
FROM FIRST NATIONAL BANK OF SOUTH AFRICA (F.N.B)..rtf Description: MS-Word document
