> From: Mario Limonciello
> Date: Mon, 11 Jul 2016 19:58:04 -0500
>
> > The RTL8153-AD supports a persistent system specific MAC address.
> > This means a device plugged into two different systems with host
> > side support will show different (but persistent) MAC addresses.
> >
> > This informa
Thanks Alan, I will do that :-)
--
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
On Tuesday, 12 July 2016 01:50:59 CEST, Greg KH wrote:
There is, as far as I can tell, no set of "default" termios values for
any type of serial port, so the "last" set of them is as good as any,
right?
Each driver specifies an initial value
(usb_serial_tty_driver->init_termios), and this valu
Some SATA to USB bridges fail to cooperate with some
drives resulting in no cache being present being reported
to the host. That causes the host to skip sending
a command to synchronize caches. That causes data loss
when the drive is powered down.
Signed-off-by: Oliver Neukum
---
Documentation/k
> -Original Message-
> From: Peter Chen [mailto:hzpeterc...@gmail.com]
> Sent: Monday, July 11, 2016 12:14 PM
> To: Rajesh Bhagat
> Cc: linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org;
> devicet...@vger.kernel.org; Peter Chen ;
> gre...@linuxfoundation.org; kis...@ti.com; robh...
Add compatible string for imx7d-usbmisc.
Signed-off-by: Li Jun
---
Documentation/devicetree/bindings/usb/usbmisc-imx.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/usb/usbmisc-imx.txt
b/Documentation/devicetree/bindings/usb/usbmisc-imx.txt
index 3539d4
Some gadget device (such as dwc3 gadget) requires quirk_ep_out_aligned_size
attribute, which means it need to align the request buffer's size to an ep's
maxpacketsize.
Thus we add usb_ep_align_maybe() function to check if it is need to align
the request buffer's size to an ep's maxpacketsize.
Sig
As all usb power supply use low active for over current flag on imx6
imx7 boards, and the default register setting(0) is for high active,
this patch is to correct it.
Signed-off-by: Li Jun
---
drivers/usb/chipidea/usbmisc_imx.c | 18 --
1 file changed, 16 insertions(+), 2 deletio
> -Original Message-
> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> Sent: Tuesday, July 12, 2016 10:24 AM
> To: Lipengcheng; gre...@linuxfoundation.org; st...@rowland.harvard.edu;
> chasemetzge...@gmail.com; mathias.ny...@linux.intel.com;
> oneu...@suse.com; jun...@freescale.com
>
Hi,
I was working on an "usbport" LED trigger driver and specifying its
default state in DT. I realized I can't really determine numbering of
USB ports on any device as it depends on compiled drivers and the
loading orders.
It means that my physical USB port can be e.g. 1-1 or 2-1 depending on
my
This allows specifying USB ports that should be observed by a trigger
right after activating it. Example:
usb {
gpios = <&gpio 0 GPIO_ACTIVE_HIGH>;
linux,default-trigger = "usbport";
usb-controllers = <&ohci>, <&ehci>, <&xhci>;
usb-ports = "1", "1", "1";
};
Signed-
This allows platforms using e.g. "generic-ohci" to reference HCD using
recently introduced providers mechanism
Signed-off-by: Rafał Miłecki
---
drivers/usb/host/ohci-platform.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-p
When working with Device Tree we may need to reference controllers
(their nodes) and query for HCDs. This is useful for getting some
runtime info about host controllers like e.g. assigned bus number.
Signed-off-by: Rafał Miłecki
---
drivers/usb/core/Makefile| 1 +
drivers/usb/core/provider.
> -Original Message-
> From: Michał Pecio [mailto:michal.pe...@gmail.com]
> Sent: Tuesday, July 12, 2016 2:03 AM
> To: David Miller
> Cc: Limonciello, Mario ; linux-
> ker...@vger.kernel.org; net...@vger.kernel.org; linux-
> u...@vger.kernel.org; anthony.w...@canonical.com
> Subject: Re: [
On Sat, 9 Jul 2016, Mauro Carvalho Chehab wrote:
> C/C linux-usb Mailing list:
>
>
> Em Wed, 18 May 2016 08:52:28 -0600
> Wade Berrier escreveu:
...
> > > That message above links to some other threads describing the issue.
> > > Here's a post with a patch that supposedly works:
> > >
> > >
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 glu
From: Peter Chen
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.
Signed-off-by: Peter Chen
Signed-off-by: Maciej S. Szmigiero
---
arch/arm/boot/dts/im
Add optional properties for power sequence.
Signed-off-by: Peter Chen
---
Documentation/devicetree/bindings/usb/usb-device.txt | 9 +
1 file changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/usb-device.txt
b/Documentation/devicetree/bindings/usb/usb-device.txt
Add binding doc for generic power sequence library.
Signed-off-by: Peter Chen
---
.../bindings/power/pwrseq/pwrseq-generic.txt | 53 ++
1 file changed, 53 insertions(+)
create mode 100644
Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
diff --git a/
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 crea
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 recogniz
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], I use a generic
power sequence library for parsing the power sequence elements on DT,
and implement generic power sequence on library. The host driver
can allocat
Dear Heiko,
On 2016/7/10 7:47, Heiko Stuebner wrote:
Am Samstag, 9. Juli 2016, 11:38:00 schrieb William.wu:
Dear Heiko & Balbi，
On 2016/7/8 21:29, Felipe Balbi wrote:
Hi,
Heiko Stuebner writes:
Am Donnerstag, 7. Juli 2016, 10:54:24 schrieb William Wu:
Add a quirk to configure the core to
The reason for the random disconnects is apparently EMI related.
Mar 1 07:09:09 localhost kernel: [265922.921985] hub 5-0:1.0: port 1
disabled by hub (EMI?), re-enabling...
This is very much a possibility because the box is in a high current
industrial control panel. That is not an issue because
Dear Rob,
On 2016/7/11 22:54, Rob Herring wrote:
On Fri, Jul 08, 2016 at 02:33:09PM +0200, Heiko Stuebner wrote:
Hi William,
Am Donnerstag, 7. Juli 2016, 10:54:24 schrieb William Wu:
Add a quirk to configure the core to support the
UTMI+ PHY with an 8- or 16-bit interface. UTMI+ PHY
interfac
Dear Rob,
On 2016/7/11 23:13, Rob Herring wrote:
On Thu, Jul 07, 2016 at 10:58:44AM +0800, William Wu wrote:
This patch adds the devicetree documentation required for Rockchip
USB3.0 core wrapper consisting of USB3.0 IP from Synopsys.
It supports DRD mode, and could operate in device mode (SS
Dear Rob,
On 2016/7/11 22:58, Rob Herring wrote:
On Thu, Jul 07, 2016 at 10:54:24AM +0800, William Wu wrote:
Add a quirk to configure the core to support the
UTMI+ PHY with an 8- or 16-bit interface. UTMI+ PHY
interface is hardware property, and it's platform
dependent. Normall, the PHYIf can
On Wed, Jul 13, 2016 at 08:58:48AM +0530, Malith Yapa wrote:
> The reason for the random disconnects is apparently EMI related.
>
> Mar 1 07:09:09 localhost kernel: [265922.921985] hub 5-0:1.0: port 1
> disabled by hub (EMI?), re-enabling...
>
> This is very much a possibility because the box is
On Tue, Jul 12, 2016 at 02:35:18PM +0200, Rafał Miłecki wrote:
> Hi,
>
> I was working on an "usbport" LED trigger driver and specifying its
> default state in DT. I realized I can't really determine numbering of
> USB ports on any device as it depends on compiled drivers and the
> loading orders.
On 13 July 2016 at 06:51, Peter Chen wrote:
> On Tue, Jul 12, 2016 at 02:35:18PM +0200, Rafał Miłecki wrote:
>> I was working on an "usbport" LED trigger driver and specifying its
>> default state in DT. I realized I can't really determine numbering of
>> USB ports on any device as it depends on c
I think i am.
int readDword(int addr) {
uint16_t reg[1];// will store read registers values
int num = modbus_read_registers(ctx, addr, 1, reg); //16386 = X2
usleep(5);
if (num != 1) {
fprintf(stderr, "Failed(%i) to read: %s\n", num,
modbus_strerror(errno));
Hi Felipe:
Could you please give me some suggestions if you have already reviewed
some codes.
Thanks a lot.
On Wed, 2016-06-15 at 11:07 +0800, Chunfeng Yun wrote:
> From 48552e96e4e33f8830cb6a59154fe148425532fd Mon Sep 17 00:00:00 2001
> From: Chunfeng Yun
> Date: Wed, 15 Jun 2016 10:58:10 +08
> So in order to hit this hypothetical corner case today you would
> need to be using a real world type-C device something such as a
> Dell WD15 on another OEM's machine that has type-C and the exact
> same ACPI object name that does $BADSTUFF other than return a
> buffer.
Exactly what I meant.
33 matches
Mail list logo
