On 06/01/2016 01:59 PM, Peter Chen wrote:
> On Wed, Jun 01, 2016 at 10:02:21AM +0200, Krzysztof Kozlowski wrote:
>> On Odroid U3 (Exynos4412-based) board if USB was initialized by
>> bootloader (in U-Boot "usb start" before tftpboot), the HUB (usb3503)
>> and LAN (smsc95xx) after after successful p
Greg KH writes:
> And finally, this seems odd overall given that a MAC address should be
> associated with the specific network device, not the overall system.
Definitely.
I wonder if this isn't a perfect candidate for an x86
arch_get_platform_mac_address() implementation? Then you could just
Hi! As ACPI bytecode is untrusted for me and also for running kernel, we
should not expect that it does not contain any bugs or other problems.
So I would propose these checks to prevent something wrong...
On Wednesday 01 June 2016 16:50:44 Mario Limonciello wrote:
> +static void set_auxiliary_add
On Wed, 2016-06-01 at 23:37 -0700, Guenter Roeck wrote:
> On 06/01/2016 11:24 PM, Oliver Neukum wrote:
> > On Wed, 2016-06-01 at 06:34 -0700, Guenter Roeck wrote:
> >> The class code would not explicitly learn about the reset,
> >> but it would be informed about the exited modes.
> >
> > That has d
On Wed, Jun 01, 2016 at 11:26:09AM +0200, Oliver Neukum wrote:
> On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote:
> > Just noticed that the "active" file is for now read only, but it needs
> > to be changed to writable. That file will of course provide means for
> > the userspace to Exit a
On Thu, Jun 02, 2016 at 09:26:57AM +0200, Krzysztof Kozlowski wrote:
> On 06/01/2016 01:59 PM, Peter Chen wrote:
> > On Wed, Jun 01, 2016 at 10:02:21AM +0200, Krzysztof Kozlowski wrote:
> >> On Odroid U3 (Exynos4412-based) board if USB was initialized by
> >> bootloader (in U-Boot "usb start" befor
writes:
>> > +static u8 amac_ascii_to_hex(int c)
>> > +{
>> > + if (c <= 0x39)
>> > + return (u8)(c - 0x30);
>> > + else if (c <= 0x46)
>> > + return (u8)(c - 0x37);
>> > + return (u8)(c - 0x57);
>> > +}
>>
>
> Sorry forgot to address this.
>
>> We really don't have such a
Adds support for the Araneus Alea I USB hardware Random Number
Generator. This RNG creates entropy at a high rate, about 100kb/s.
Signed-off-by: Bob Ham
---
Just a note about the name of the module, I haven't append "-rng" to
the name, like every other module in hw_random, because those modules
On Thu, Jun 02, 2016 at 08:30:57AM +0200, Oliver Neukum wrote:
> On Wed, 2016-06-01 at 16:29 -0700, Guenter Roeck wrote:
> > On Wed, Jun 01, 2016 at 11:26:09AM +0200, Oliver Neukum wrote:
> > > On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote:
> > > > Just noticed that the "active" file is
On Wed, Jun 01, 2016 at 04:29:26PM -0700, Guenter Roeck wrote:
> On Wed, Jun 01, 2016 at 11:26:09AM +0200, Oliver Neukum wrote:
> > On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote:
> > > Just noticed that the "active" file is for now read only, but it needs
> > > to be changed to writable.
hi,
John Youn writes:
> On 5/30/2016 7:19 AM, Felipe Balbi wrote:
>> Instead of looping through all endpoints when
>> enabling ep0, let's allow for each endpoint to set
>> its own xfer resource. This solves an issue which
>> happens when we issue END_TRANSFER due to a reset
>> interrupt. Endpoin
Bob Ham wrote:
> Adds support for the Araneus Alea I USB hardware Random Number
> Generator. This RNG creates entropy at a high rate, about 100kb/s.
>
> Signed-off-by: Bob Ham
> ---
>
> +++ b/drivers/char/hw_random/alea.c
Why didn't you just add the device ID to chaoskey.c?
(Because that one is
On 01/06/16 10:38, Peter Chen wrote:
> On Fri, May 13, 2016 at 01:03:27PM +0300, Roger Quadros wrote:
>> @@ -530,6 +683,8 @@ void usb_del_gadget_udc(struct usb_gadget *gadget)
>> }
>> mutex_unlock(&udc_lock);
>>
>> +mutex_unlock(&udc_lock);
>> +
>
> Here, you have one more mutex_un
On Thu, 2016-06-02 at 12:43 +0200, Clemens Ladisch wrote:
> Bob Ham wrote:
> > Adds support for the Araneus Alea I USB hardware Random Number
> > Generator. This RNG creates entropy at a high rate, about 100kb/s.
> >
> > Signed-off-by: Bob Ham
> > ---
> >
> > +++ b/drivers/char/hw_random/alea.c
>
On 06/01/2016 10:46 AM, Roger Quadros wrote:
Implementations might use different IRQs for
host, gadget and OTG so use named interrupt resources
to allow Device tree to specify the 3 interrupts.
Following are the interrupt names
Peripheral Interrupt - peripheral
HOST Interrupt - host
OTG Interru
hi,
Felipe Balbi writes:
>> This reverts back to the original buggy behavior. This will fail when
>> a SET_INTERFACE occurs multiple times.
>>
>> You can run testusb to see the failure:
>> testusb -t 9 -c 5000 -s 2048 -a
>
> I came up with something else for this. It's still unstable and I need
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, HS, FS)
and host mode (SS, HS, FS, LS).
Signed-off-by: William Wu
---
Changes in v4:
- modify commit log, and
Add a quirk to clear the GUSB2PHYCFG.U2_FREECLK_EXISTS bit,
which specifies whether the USB2.0 PHY provides a free-running
PHY clock, which is active when the clock control input is active.
Signed-off-by: William Wu
---
Changes in v4:
- rebase on top of balbi testing/next, remove pdata (balbi)
C
Add a quirk to clear the GUSB3PIPECTL.DELAYP1TRANS bit,
which specifies whether disable delay PHY power change
from P0 to P1/P2/P3 when link state changing from U0
to U1/U2/U3 respectively.
Signed-off-by: William Wu
---
Changes in v4:
- rebase on top of balbi testing/next, remove pdata (balbi)
C
Rockchip platform merely enable usb3 clocks and
populate its children. So we can use this generic
glue layer to support Rockchip dwc3.
Signed-off-by: William Wu
---
Changes in v4:
- None
Changes in v3:
- None
Changes in v2:
- sort the list of_dwc3_simple_match (Doug)
drivers/usb/dwc3/dwc3-of-
This series add support for rockchip dwc3 driver,
and add additional optional properties for specific
platforms (e.g., rockchip rk3399 platform).
William Wu (5):
usb: dwc3: of-simple: add compatible for rockchip
usb: dwc3: add dis_u2_freeclk_exists_quirk
usb: dwc3: add phyif_utmi_quirk
usb
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 be configured
during coreconsultant. But for some specific usb
cores(e.g. rk3399 soc dwc3), the default PHYIf
conf
> -Original Message-
> From: Bjørn Mork [mailto:bj...@mork.no]
> Sent: Thursday, June 2, 2016 3:11 AM
> To: Limonciello, Mario
> Cc: gre...@linuxfoundation.org; hayesw...@realtek.com; linux-
> ker...@vger.kernel.org; net...@vger.kernel.org; linux-
> u...@vger.kernel.org; pali.ro...@gmail
This adds a driver for the Pegasus Notetaker Pen. When connected,
this uses the Pen as an input tablet.
This device was sold in various different brandings, for example
"Pegasus Mobile Notetaker M210",
"Genie e-note The Notetaker",
"Staedtler Digital ballpoint pen 990 01",
"IRISnotes Express"
Thanks for the check. Some small comments below, and I'll address in next
submission.
> -Original Message-
> From: Pali Rohár [mailto:pali.ro...@gmail.com]
> Sent: Thursday, June 2, 2016 2:47 AM
> To: Limonciello, Mario
> Cc: hayesw...@realtek.com; LKML ; Netdev
> ; Linux USB ;
> anthon
Hi!
I am trying to add support for force feedback for the "Fanatec Clubsport
Wheel Base V2". (More information at
http://www.fanatec.com/eu-de/wheel-bases/clubsport-wheel-base-v2-eu-eu.html
)
It is a configurable racing wheel for enthusiasts.
Using a simple hack (by handling it somewhat like a Lo
> >
> > > + pr_info("r8152: Using system auxiliary MAC address");
> >
> > It would be great to write also mac address into that pr_info
And since there could be multiple r8152 in the system, it would be
good to indicate which of them is having its MAC changed. So
netdev_info() or dev_inf
> -Original Message-
> From: Andrew Lunn [mailto:and...@lunn.ch]
> Sent: Thursday, June 2, 2016 10:01 AM
> To: Limonciello, Mario
> Cc: pali.ro...@gmail.com; hayesw...@realtek.com; linux-
> ker...@vger.kernel.org; net...@vger.kernel.org; linux-
> u...@vger.kernel.org; anthony.w...@canoni
At least the EHCI/OHCI found on the Allwinnner H3 SoC needs multiple
reset lines, the controller will not initialize while the reset for
its companion is still asserted, which means we need to de-assert
2 resets for the controller to work.
Signed-off-by: Hans de Goede
---
Changes in v2:
-New patc
Here is a resend of my last version of the patch set to support usb
controllers which have multiple resets.
The shared reset controller support this depends on has landed in 4.7-rc1,
so this patch-set should be ready for merging now.
Changes in v2:
-Switch to now shared reset_[de]assert functions
From: Reinder de Haan
At least the EHCI/OHCI found on the Allwinnner H3 SoC needs multiple
reset lines, the controller will not initialize while the reset for
its companion is still asserted, which means we need to de-assert
2 resets for the controller to work.
Signed-off-by: Reinder de Haan
Si
On Thu, Jun 02, 2016 at 02:10:37AM +, mario_limoncie...@dell.com wrote:
> > -Original Message-
> > From: Greg KH [mailto:gre...@linuxfoundation.org]
> > Sent: Wednesday, June 1, 2016 6:06 PM
> > To: Limonciello, Mario
> > Cc: hayesw...@realtek.com; LKML ; Netdev
> > ; Linux USB ;
> > p
> >
> > This isn't something part of ACPI - it's been added specifically for a
> > selection of Dell machines.
>
> Ah, but isn't ACPI supposed to be a "standard"? :)
>
Heh.
It's also possible to get this from an SMM routine. Lesser of two evils to
fetch the information this way, right? :)
>
On Thu, Jun 02, 2016 at 05:00:55PM +0200, Florian Fischer wrote:
> Hi!
>
> I am trying to add support for force feedback for the "Fanatec Clubsport
> Wheel Base V2". (More information at
> http://www.fanatec.com/eu-de/wheel-bases/clubsport-wheel-base-v2-eu-eu.html
> )
> It is a configurable racing
On Thu, Jun 02, 2016 at 03:46:41PM +, mario_limoncie...@dell.com wrote:
> > >
> > > This isn't something part of ACPI - it's been added specifically for a
> > > selection of Dell machines.
> >
> > Ah, but isn't ACPI supposed to be a "standard"? :)
> >
>
> Heh.
> It's also possible to get th
On Thu, Jun 02, 2016 at 01:18:53PM +0300, Heikki Krogerus wrote:
> On Wed, Jun 01, 2016 at 04:29:26PM -0700, Guenter Roeck wrote:
> > On Wed, Jun 01, 2016 at 11:26:09AM +0200, Oliver Neukum wrote:
> > > On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote:
> > > > Just noticed that the "active"
Some of my comments are getting stale with what I've done in response to all
these emails.
Let me send a v2 that we can better iterate on, a few comments below though.
> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Thursday, June 2, 2016 11:09 AM
> To: Li
Dell systems with Type-C ports have support for a persistent system
specific MAC address when used with Dell Type-C docks and dongles.
This means a dock plugged into two different systems will show different
(but persistent) MAC addresses. Dell Type-C docks and dongles use the
r8152 driver.
This
This adjusts a lot of concerns that have been raised on LKML.
Changes from v1:
* Lots of error checking around bad ACPI data
* Only activate on Dell system vendor DMI string
* Use hex2bin instead of inventing a wheel
* Copy MAC to both dev_addr and sa_data
* Track and set only for one NIC at
phy-sun4i-usb now has proper dr_mode handling, it always registers an
extcon, and sends a notify with the mode (even when in peripheral- /
host-only mode) at least once.
So we can simply the sunxi musb glue by always registering its extcon
notifier and relying on sunxi_musb_work() to enable vbus w
Use the new of_usb_get_dr_mode_by_phy() function to get the dr_mode
from the musb controller node instead of assuming that having an id_det
gpio means otg mode, and not having one means host mode.
Implement peripheral-only mode by adding a sun4i_usb_phy0_get_id_det
helper which looks at the dr_mod
Some SoCs have a single phy-hw-block with multiple phys, this is
modelled by a single phy dts node, so we end up with multiple
controller nodes with a phys property pointing to the phy-node
of the otg-phy.
Only one of these controllers typically is an otg controller, yet we
were checking the first
The A31 companion pmic (axp221) does not generate vbus change interrupts
when the board is driving vbus, so we must poll when using the pmic for
vbus-det _and_ we're driving vbus.
Signed-off-by: Hans de Goede
---
drivers/phy/phy-sun4i-usb.c | 34 --
1 file changed
On Thu, Jun 02, 2016 at 11:58:07AM -0500, Mario Limonciello wrote:
> Dell systems with Type-C ports have support for a persistent system
> specific MAC address when used with Dell Type-C docks and dongles.
> This means a dock plugged into two different systems will show different
> (but persistent)
We have been dereferencing udc before checking it. Lets use it after it
has been checked.
Signed-off-by: Sudip Mukherjee
---
drivers/usb/usbip/vudc_sysfs.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/usbip/vudc_sysfs.c b/drivers/usb/usbip/vudc_sysfs.c
i
writes:
>> > 2) Track whether this is the first or second USB NIC plugged in. Only
>> > offer it
>> on the first NIC detected by r8152. When the second NIC is plugged in don't
>> match from ACPI.
>> > There would be a question of what to do if the first NIC is removed and
>> added back if it s
On 6/1/2016 11:38 PM, Felipe Balbi wrote:
>
> Hi,
>
> John Youn writes:
However, I'm not aware of any issue with END_TRANSFER, could you let
me know how to reproduce it?
>>>
>>> it's a rare and difficult bug to reproduce. If you take my testing/next
>>> (I didn't check if it happens wi
Hi,
On Thu, Jun 02, 2016 at 07:31:03PM +0200, Hans de Goede wrote:
> Some SoCs have a single phy-hw-block with multiple phys, this is
> modelled by a single phy dts node, so we end up with multiple
> controller nodes with a phys property pointing to the phy-node
> of the otg-phy.
>
> Only one of
On 6/1/2016 11:38 PM, Felipe Balbi wrote:
>
> Hi,
>
> John Youn writes:
However, I'm not aware of any issue with END_TRANSFER, could you let
me know how to reproduce it?
>>>
>>> it's a rare and difficult bug to reproduce. If you take my testing/next
>>> (I didn't check if it happens wi
> -Original Message-
> From: Bjørn Mork [mailto:bj...@mork.no]
> Sent: Thursday, June 2, 2016 1:04 PM
> To: Limonciello, Mario
> Cc: gre...@linuxfoundation.org; hayesw...@realtek.com; linux-
> ker...@vger.kernel.org; net...@vger.kernel.org; linux-
> u...@vger.kernel.org; pali.ro...@gmail.c
> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Thursday, June 2, 2016 12:48 PM
> To: Limonciello, Mario
> Cc: hayesw...@realtek.com; LKML ; Netdev
> ; Linux USB ;
> pali.ro...@gmail.com; anthony.w...@canonical.com
> Subject: Re: [PATCH v2] r8152: Add suppo
On Thursday 02 June 2016 20:04:02 Bjørn Mork wrote:
> writes:
> >> > 2) Track whether this is the first or second USB NIC plugged in.
> >> > Only offer it
> >>
> >> on the first NIC detected by r8152. When the second NIC is
> >> plugged in don't match from ACPI.
> >>
> >> > There would be a qu
On 6/2/2016 5:26 AM, Felipe Balbi wrote:
>
> hi,
>
> Felipe Balbi writes:
>>> This reverts back to the original buggy behavior. This will fail when
>>> a SET_INTERFACE occurs multiple times.
>>>
>>> You can run testusb to see the failure:
>>> testusb -t 9 -c 5000 -s 2048 -a
>>
>> I came up with
> > And you want to check this for all Dell devices? Please be model
> > specific, I doubt a bunch of Dell servers wants to run this code...
> >
>
> Tracking model specific is really going to turn into a giant list never
> ending list.
> To drill down more specifically, I can match on chassis t
On Thursday 02 June 2016 20:28:33 mario_limoncie...@dell.com wrote:
> > -Original Message-
> > From: Bjørn Mork [mailto:bj...@mork.no]
> > Sent: Thursday, June 2, 2016 1:04 PM
> > To: Limonciello, Mario
> > Cc: gre...@linuxfoundation.org; hayesw...@realtek.com; linux-
> > ker...@vger.kerne
> -Original Message-
> From: Andrew Lunn [mailto:and...@lunn.ch]
> Sent: Thursday, June 2, 2016 2:03 PM
> To: Limonciello, Mario
> Cc: gre...@linuxfoundation.org; hayesw...@realtek.com; linux-
> ker...@vger.kernel.org; net...@vger.kernel.org; linux-
> u...@vger.kernel.org; pali.ro...@gmail
On Thu, Jun 02, 2016 at 07:04:32PM +, mario_limoncie...@dell.com wrote:
> > -Original Message-
> > From: Andrew Lunn [mailto:and...@lunn.ch]
> > Sent: Thursday, June 2, 2016 2:03 PM
> > To: Limonciello, Mario
> > Cc: gre...@linuxfoundation.org; hayesw...@realtek.com; linux-
> > ker...@
> I have some other questions which answers should we know:
>
> 1) Is that AUX MAC address implemented only in customized windows Dell
> driver? Or also in "upstream" windows Realtek driver and all users of
> Realtek hw can install it (or update via next driver update)?
>
I don't have the inform
This adds tracepoints to musb register read/write wrappers to get
trace log for register access.
The default tacepoint log prefix here would be musb_readX/writeX(), which
is not much helpful. So here the tracepoints use __buildin_return_address(0)
to print the caller funciton name to provide more
Switch dev_dbg() to tracepoint debug musb_dbg().
Signed-off-by: Bin Liu
---
drivers/usb/musb/cppi_dma.c| 36 ++---
drivers/usb/musb/musb_core.c | 57 ++--
drivers/usb/musb/musb_cppi41.c | 8 +--
drivers/usb/musb/musb_gadget.c | 94 ++
This adds tracepoints to dump musb interrupt events.
Signed-off-by: Bin Liu
---
drivers/usb/musb/musb_core.c | 4 +---
drivers/usb/musb/musb_trace.h | 22 ++
2 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb
To avoid printk() overhead while debugging, this patch implements the
foundation of tracepoints logging for musb driver to make debug
easier.
Signed-off-by: Bin Liu
---
drivers/usb/musb/Makefile | 5 +++-
drivers/usb/musb/musb_debug.h | 2 ++
drivers/usb/musb/musb_trace.c | 33
Add usb_request tracepoints for gadget mode.
Signed-off-by: Bin Liu
---
drivers/usb/musb/musb_gadget.c | 35 ---
drivers/usb/musb/musb_trace.h | 78 +-
2 files changed, 91 insertions(+), 22 deletions(-)
diff --git a/drivers/usb/musb/musb_
Hi,
I have added tracepoints in musb in my local tree since a year+ ago, mainly
used to dump register access logs for my debugging. Now I extended it to cover
more debug cases, tracing urb, usb_request, and also converted dev_dbg() to
tracepoints.
Please review them and let me know your commen
musb core already exports the register read/write wrappers, so clean up
the duplication in dsps glue.
Signed-off-by: Bin Liu
---
drivers/usb/musb/musb_dsps.c | 112 +--
1 file changed, 44 insertions(+), 68 deletions(-)
diff --git a/drivers/usb/musb/musb_d
Add urb tracepoints for host mode.
Signed-off-by: Bin Liu
---
drivers/usb/musb/musb_host.c | 34 ++-
drivers/usb/musb/musb_trace.h | 63 +++
2 files changed, 71 insertions(+), 26 deletions(-)
diff --git a/drivers/usb/musb/musb_host.c
tree: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
testing/next
head: 327475d7f63aa161bdc3bf7f9d693d9aafcd4518
commit: bcf4420283d1338b39773be8b487563c90986959 [64/67] usb: gadget: move
gadget API functions to udc-core
config: arm-mvebu_v7_defconfig (attached as .config)
comp
Hi,
On Wed, Jun 01, 2016 at 09:40:06AM -0400, Sandhya Bankar wrote:
> Use sizeof(*qh)instead of sizeof *qh.
>
> Signed-off-by: Sandhya Bankar
Please revise the subject prefix to "usb: musb: host: ...".
Regards,
-Bin.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
t
Hi,
On Wed, Jun 01, 2016 at 09:49:35AM -0400, Sandhya Bankar wrote:
> Add space after that ','.
>
> Signed-off-by: Sandhya Bankar
Please revise the subject prefix to "usb: musb: musbhsdma: ...".
Regards,
-Bin.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body
On Wed, Jun 01, 2016 at 12:29:59PM +0800, Wenyou Yang wrote:
> In order to the save power consumption, as a workaround, suspend
> forcibly the USB PORTA/B/C via set the SUSPEND_A/B/C bits of OHCI
> Interrupt Configuration Register in the SFRs while OHCI USB suspend.
>
> This suspend operation must
You are a recipient to Mr Pedro Quezada Donation of 2M USD. Contact
(qpedro...@gmail.com) for claims.
--
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 Thu, Jun 02, 2016 at 06:32:42PM +, mario_limoncie...@dell.com wrote:
> > And you want to check this for all Dell devices? Please be model
> > specific, I doubt a bunch of Dell servers wants to run this code...
> >
>
> Tracking model specific is really going to turn into a giant list never
On Wed, Jun 01, 2016 at 10:02:15AM +0200, Krzysztof Kozlowski wrote:
> Some devices need real hard-reset by cutting the power. During power
> sequence turn off and on the regulator, if it is provided.
>
> Additionally add support for instantiating the pwrseq-simple device on a
> generic property
On Mon, May 30, 2016 at 01:47:12PM -0700, Greg KH wrote:
> On Mon, May 30, 2016 at 09:02:54PM +0200, Marc Haber wrote:
> > Hi,
> >
> > on my Bananapis, in kernel 4.6 USB does not work. Kernel configuration
> > is USB-wise identical to 4.5 (grepped for differences in (hci|usb)),
> > and in 4.6 ther
74 matches
Mail list logo
