Re: [PATCH v3 3/7] usb: mux: add common code for Intel dual role port mux

Hi, On 03/11/2016 07:57 AM, Greg Kroah-Hartman wrote: > On Thu, Mar 10, 2016 at 01:39:43PM +0100, Oliver Neukum wrote: >> On Tue, 2016-03-08 at 15:53 +0800, Lu Baolu wrote: >> >>> diff --git a/Documentation/ABI/testing/sysfs-bus-platform >>> b/Documentation/ABI/testing/sysfs-bus-platform >>>

RE: [PATCH v6 12/12] usb: host: xhci-plat: Add otg device to platform data

Hi, > Sent: Tuesday, April 05, 2016 11:05 PM > > Host controllers that are part of an OTG/dual-role instance > need to somehow pass the OTG controller device information > to the HCD core. > > We use platform data to pass the OTG controller device. > > Signed-off-by: Roger Quadros

Re: [PATCH v9 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

On Tue, Apr 05, 2016 at 09:53:05AM -0700, Mark Brown wrote: > > > > The framework does not want to focus on charger detection too much, > > > and just supplies one callback '->charger_detect()' for user to be > > > implemented if they ensure they need to do the SW charger detection > > > manually

RE: EXT :Re: [RFC] Create an audit record of USB specific details

On Tue, 2016-04-05 at 14:42 +, Boyce, Kevin P (AS) wrote: > Burn, > > > Hence my final comment below about well known devices and the desire > > monitor open/openat/etc for write system calls on 'deemed removable media' > > ie one day we could set up > auditctl -F arch=b64 -a always,exit

Re: [PATCH] usb: f_mass_storage: test whether thread is running before starting another

On Tue, Apr 05 2016, Alan Stern wrote: > Suppose one usb_function is carrying out an I/O operation while > another one in the same config gets a Set-Interface request from the > host. That cannot happen. A single instance of mass_storage cannot¹ be added twice to the same configuration. ¹ To be

Re: [RFC] Create an audit record of USB specific details

On Tue, Apr 05, 2016 at 03:38:34PM -0400, Steve Grubb wrote: > On Tuesday, April 05, 2016 07:02:48 PM Oliver Neukum wrote: > > On Tue, 2016-04-05 at 18:40 +1000, Wade Mealing wrote: > > > Consider the following scenario. Currently we have device drivers > > > that emit text via a printk request

Re: [RFC] Create an audit record of USB specific details

O > > If you want a place in the kernel to add audit records for all devices > added to or removed from the system, the right place to do it is in > drivers/base/core.c, the device_add() and device_del() routines. > That's where the ADD and REMOVE uevents are created. > > Alan Stern I agree with

Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

Hi Heiner, Thanks for the feedback. On 04/05/2016 10:43 PM, Heiner Kallweit wrote: Am 05.04.2016 um 21:45 schrieb Jacek Anaszewski: On 04/05/2016 11:01 AM, Pavel Machek wrote: Hi! It would have the same downsides as in case of having r, g and b in separate attributes, i.e. - problems with

Re: [PATCH v10 3/9] dt-bindings: phy: tegra-xusb-padctl: Add Tegra210 support

On 04/05/2016 08:44 AM, Thierry Reding wrote: On Wed, Mar 16, 2016 at 11:59:44AM -0600, Stephen Warren wrote: On 03/04/2016 09:19 AM, Thierry Reding wrote: From: Thierry Reding Extend the binding to cover the set of feature found in Tegra210. Acked-by: Stephen Warren

Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

Am 05.04.2016 um 21:45 schrieb Jacek Anaszewski: > On 04/05/2016 11:01 AM, Pavel Machek wrote: >> Hi! >> >>> It would have the same downsides as in case of having r, g and b in >>> separate attributes, i.e. - problems with setting LED colour in >>> a consistent way. This way LED

Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

On 04/05/2016 11:01 AM, Pavel Machek wrote: Hi! It would have the same downsides as in case of having r, g and b in separate attributes, i.e. - problems with setting LED colour in a consistent way. This way LED blinking in whatever colour couldn't be supported reliably. It was one of your

Re: [RFC] Create an audit record of USB specific details

On Tuesday, April 05, 2016 07:02:48 PM Oliver Neukum wrote: > On Tue, 2016-04-05 at 18:40 +1000, Wade Mealing wrote: > > Consider the following scenario. Currently we have device drivers > > that emit text via a printk request which is eventually picked up by > > syslog like implementation (not

[PATCH RESEND 2/2] ARM: socfpga: dts: add reset control for USB

From: Dinh Nguyen Add the resets property for the 2 USB controllers. Signed-off-by: Dinh Nguyen Cc: John Youn Cc: Felipe Balbi --- arch/arm/boot/dts/socfpga.dtsi |4

Re: [PATCH] usb: f_mass_storage: test whether thread is running before starting another

On Tue, 5 Apr 2016, Michal Nazarewicz wrote: > > On Tue, 5 Apr 2016, Michal Nazarewicz wrote: > >> When binding the function to usb_configuration, check whether the thread > >> is running before starting another one. Without that, when function > >> instance is added to multiple configurations,

[PATCH RESEND 1/2] usb: dwc2: Add reset control to dwc2

From: Dinh Nguyen Allow for platforms that have a reset controller driver in place to bring the USB IP out of reset. Signed-off-by: Dinh Nguyen Cc: John Youn Cc: Felipe Balbi --- Resend

Re: [PATCH] usb: f_mass_storage: test whether thread is running before starting another

> On Tue, 5 Apr 2016, Michal Nazarewicz wrote: >> When binding the function to usb_configuration, check whether the thread >> is running before starting another one. Without that, when function >> instance is added to multiple configurations, fsg_bing starts multiple >> threads with all but the

Re: [PATCH] usb: f_mass_storage: test whether thread is running before starting another

On Tue, 5 Apr 2016, Michal Nazarewicz wrote: > When binding the function to usb_configuration, check whether the thread > is running before starting another one. Without that, when function > instance is added to multiple configurations, fsg_bing starts multiple > threads with all but the latest

[PATCH] usb: f_mass_storage: test whether thread is running before starting another

When binding the function to usb_configuration, check whether the thread is running before starting another one. Without that, when function instance is added to multiple configurations, fsg_bing starts multiple threads with all but the latest one being forgotten by the driver. This leads to

Re: [RFC] Create an audit record of USB specific details

On Tue, 2016-04-05 at 18:40 +1000, Wade Mealing wrote: > Consider the following scenario. Currently we have device drivers > that emit text via a printk request which is eventually picked up by > syslog like implementation (not the audit subsystem). We also have UEVENTs. The crucial question is

Re: [PATCH v9 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

On Tue, Apr 05, 2016 at 05:43:20PM +0800, Peter Chen wrote: > On Tue, Apr 05, 2016 at 05:34:02PM +0800, Baolin Wang wrote: > > Mark, could you please address Peter's comments about if the the > > wm831x can charge more than 1500mA for DCP? (I have no environment to > > test wm831x) Thanks. > I

Re: [PATCH v9 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

On Tue, Apr 05, 2016 at 04:12:22PM +0800, Peter Chen wrote: > On Tue, Apr 05, 2016 at 03:54:31PM +0800, Baolin Wang wrote: > > Hi Peter, > > Yeah, this patchset did not give an example to read charger type from > > PMIC registers. (Cause now the user 'wm831x_power' don't need this.) > > But I

Re: [PATCH v10 8/9] usb: xhci: Add NVIDIA Tegra XUSB controller driver

On 05.04.2016 16:35, Greg Kroah-Hartman wrote: On Tue, Apr 05, 2016 at 03:17:51PM +0200, Thierry Reding wrote: Hi Mathias, Greg, Due to the various dependencies within the series, I'd prefer this to go via the Tegra tree. Would you be okay with providing your Acked-by? That's all up to

Re: ADMtek ADM8511 "Pegasus II" USB Ethernet causes oops

Hi, I've no idea how this PEGASUS_MTU + 8 got in. Maybe somebody played games with the skb alignment over the years. I'm traveling right now so i'll look at the patch more closely when I get back. At first glance it does look OK. cheers, Petko On April 5, 2016 1:31:33 PM GMT+03:00,

Re: EXT :Re: [RFC] Create an audit record of USB specific details

On Tue, Apr 05, 2016 at 01:52:40PM +, Boyce, Kevin P (AS) wrote: > Greg, > > > There is no "/proc/usb/" :) > > Sorry, maybe /sys/bus/usb/devices was what I was looking for... > > > The kernel calls mknod itself on devtmpfs, userspace doesn't do that > > anymore (hasn't for a long time).

Re: USB gadgets with configfs hang reboot

On Fri, Apr 01 2016, Michal Nazarewicz wrote: > For legacy/nokia setting no_configfs should be a valid solution: > > >8 > diff --git a/drivers/usb/gadget/legacy/nokia.c > b/drivers/usb/gadget/legacy/nokia.c > index

Re: [RFC] Create an audit record of USB specific details

On Mon, Apr 4, 2016 at 11:39 PM, Greg KH wrote: > On Mon, Apr 04, 2016 at 10:54:56PM -0400, Paul Moore wrote: >> On April 4, 2016 6:17:23 PM Greg KH wrote: >> > On Mon, Apr 04, 2016 at 05:37:58PM -0400, Paul Moore wrote: >> > > On Monday,

Re: [RFC] Create an audit record of USB specific details

On Tue, 5 Apr 2016, Wade Mealing wrote: > I'm reframing my use case as follows to try and better explain the > situation I am trying to track. > > It might seem that I am duplicating existing functionality, rather I > am trying to augment functionality that seems to be > unavailable.Replication

[PATCH v6 10/12] usb: doc: dt-binding: Add otg-controller property

The otg-controller property is used to link the host/gadget controllers to the otg controller. otg-controller property must contain the phandle of the otg controller. The otg core uses this property to tie the host/gadget controllres to the correct otg controller. Signed-off-by: Roger Quadros

[PATCH v6 05/12] usb: gadget.h: Add OTG to gadget interface

The OTG core will use struct otg_gadget_ops to start/stop the gadget controller. The main purpose of this interface is to avoid directly calling usb_gadget_start/stop() from the OTG core as they wouldn't be defined in the built-in symbol table if CONFIG_USB_GADGET is m. Signed-off-by: Roger

RE: EXT :Re: [RFC] Create an audit record of USB specific details

On Tue, 2016-04-05 at 14:20 +, Boyce, Kevin P (AS) wrote: > In all of this discussion about auditing insertion and removal of usb > devices, I would mention that you'd want a complete solution, not just USB. > If you are trying to prevent people from stealing data or know what data they >

Re: [PATCH v10 3/9] dt-bindings: phy: tegra-xusb-padctl: Add Tegra210 support

On Wed, Mar 16, 2016 at 11:59:44AM -0600, Stephen Warren wrote: > On 03/04/2016 09:19 AM, Thierry Reding wrote: > > From: Thierry Reding > > > > Extend the binding to cover the set of feature found in Tegra210. > > Acked-by: Stephen Warren > > > diff

RE: EXT :Re: [RFC] Create an audit record of USB specific details

Burn, > Hence my final comment below about well known devices and the desire monitor > open/openat/etc for write system calls on 'deemed removable media' ie one day > we could set up auditctl -F arch=b64 -a always,exit -S open -F a1&3 -F dev=removable -k RMopen And even when you try to

Re: [RFC] Create an audit record of USB specific details

On Tue, 2016-04-05 at 09:44 -0400, Greg KH wrote: > On Tue, Apr 05, 2016 at 11:07:48PM +1000, Burn Alting wrote: > > On Mon, 2016-04-04 at 14:53 -0700, Greg KH wrote: > > > On Mon, Apr 04, 2016 at 02:48:43PM -0700, Greg KH wrote: > > > > On Mon, Apr 04, 2016 at 05:33:10PM -0400, Steve Grubb wrote:

[PATCH v6 08/12] usb: hcd: Adapt to OTG core

Introduce usb_otg_add/remove_hcd() for use by host controllers that are part of OTG/dual-role port. Non Device tree platforms can use the otg_dev argument to specify the OTG controller device. If otg_dev is NULL then the device tree node's otg-controller property is used to get the otg_dev

RE: EXT :Re: [RFC] Create an audit record of USB specific details

In all of this discussion about auditing insertion and removal of usb devices, I would mention that you'd want a complete solution, not just USB. If you are trying to prevent people from stealing data or know what data they stole (as in the case of Eric Snowden and Brad Manning) I would think

[PATCH v6 09/12] usb: gadget: udc: adapt to OTG core

The OTG state machine needs a mechanism to start and stop the gadget controller. Add usb_gadget_start() and usb_gadget_stop(). Introduce usb_otg_add_gadget_udc() to allow controller drivers to register a gadget controller that is part of an OTG instance. Register with OTG core when gadget

[PATCH v6 06/12] usb: otg: get rid of CONFIG_USB_OTG_FSM in favour of CONFIG_USB_OTG

Let's use CONFIG_USB_OTG as a single config option to enable USB OTG and the OTG FSM. This makes things a lot less confusing. Update all users of CONFIG_USB_OTG_FSM to CONFIG_USB_OTG. Signed-off-by: Roger Quadros --- Documentation/usb/chipidea.txt | 2 +- drivers/usb/Makefile

[PATCH v6 03/12] usb: otg-fsm: use usb_otg wherever possible

Move otg_fsm into usb_otg and use usb_otg wherever possible in the usb_otg APIs. Signed-off-by: Roger Quadros --- drivers/usb/chipidea/ci.h| 1 - drivers/usb/chipidea/core.c | 12 +-- drivers/usb/chipidea/debug.c | 2 +- drivers/usb/chipidea/otg_fsm.c |

[PATCH v6 07/12] usb: otg: add OTG/dual-role core

It provides APIs for the following tasks - Registering an OTG/dual-role capable controller - Registering Host and Gadget controllers to OTG core - Providing inputs to and kicking the OTG state machine Provide a dual-role device (DRD) state machine. DRD mode is a reduced functionality OTG mode.

[PATCH v6 01/12] usb: hcd: Initialize hcd->flags to 0

When using the OTG/drd library we can call hcd_add/remove consecutively without calling hcd_alloc in between so flags can be stale. If the HC dies due to whatever reason then without this patch we get the below error on next hcd_add. [ 91.494257] xhci-hcd xhci-hcd.0.auto: HC died; cleaning up

[PATCH v6 04/12] usb: otg-fsm: move host controller operations into usb_otg->hcd_ops

This is to prevent missing symbol build error if OTG is enabled (built-in) and HCD core (CONFIG_USB) is module. Signed-off-by: Roger Quadros --- drivers/usb/chipidea/otg_fsm.c | 7 +++ drivers/usb/common/usb-otg-fsm.c | 15 +++ drivers/usb/phy/phy-fsl-usb.c

[PATCH v6 00/12] USB OTG/dual-role framework

Hi, This series centralizes OTG/Dual-role functionality in the kernel. As of now I've got Dual-role functionality working pretty reliably on dra7-evm and am437x-gp-evm. DWC3 controller and platform related patches will be sent separately. Series is based on v4.6-rc1 and depends on [1] [1] - OTG

[PATCH v6 02/12] usb: hcd.h: Add OTG to HCD interface

The OTG core will use struct otg_hcd_ops to interface with the HCD controller. The main purpose of this interface is to avoid directly calling HCD APIs from the OTG core as they wouldn't be defined in the built-in symbol table if CONFIG_USB is m. Signed-off-by: Roger Quadros ---

[PATCH v6 12/12] usb: host: xhci-plat: Add otg device to platform data

Host controllers that are part of an OTG/dual-role instance need to somehow pass the OTG controller device information to the HCD core. We use platform data to pass the OTG controller device. Signed-off-by: Roger Quadros --- drivers/usb/host/xhci-plat.c | 35

[PATCH v6 11/12] usb: core: hub: Notify OTG fsm when A device sets b_hnp_enable

This is the a_set_b_hnp_enable flag in the OTG state machine diagram and must be set when the A-Host has successfully set the b_hnp_enable feature of the OTG-B-Peripheral attached to it. When this bit changes we kick our OTG FSM to make note of the change and act accordingly. Signed-off-by:

RE: EXT :Re: [RFC] Create an audit record of USB specific details

Greg, > There is no "/proc/usb/" :) Sorry, maybe /sys/bus/usb/devices was what I was looking for... > The kernel calls mknod itself on devtmpfs, userspace doesn't do that anymore > (hasn't for a long time). Do you get those audit events today? I'm not auditing those events myself. Just

Re: [PATCH v7 3/3] usb: otg-fsm: Prevent build warning "VDBG" redefined

Peter, On 05/04/16 15:52, Roger Quadros wrote: > Peter, > > On 05/04/16 11:52, Peter Chen wrote: >> On Thu, Mar 31, 2016 at 12:41:19PM +0300, Roger Quadros wrote: >>> If usb/otg-fsm.h and usb/composite.h are included together >>> then it results in the build warning [1]. >>> >>> Prevent that by

Re: EXT :Re: [RFC] Create an audit record of USB specific details

On Tue, Apr 05, 2016 at 11:49:14AM +, Boyce, Kevin P (AS) wrote: > Wade, > > Wouldn't this imply that every time the system is booted and the PCI > bus for example is enumerated and all of the devices are created that > all of those activities generate audit events? > That sounds less than

Re: [RFC] Create an audit record of USB specific details

On Tue, Apr 05, 2016 at 11:07:48PM +1000, Burn Alting wrote: > On Mon, 2016-04-04 at 14:53 -0700, Greg KH wrote: > > On Mon, Apr 04, 2016 at 02:48:43PM -0700, Greg KH wrote: > > > On Mon, Apr 04, 2016 at 05:33:10PM -0400, Steve Grubb wrote: > > > > On Monday, April 04, 2016 05:56:26 AM Greg KH

Re: [PATCH v10 8/9] usb: xhci: Add NVIDIA Tegra XUSB controller driver

On Tue, Apr 05, 2016 at 03:17:51PM +0200, Thierry Reding wrote: > Hi Mathias, Greg, > > Due to the various dependencies within the series, I'd prefer this to go > via the Tegra tree. Would you be okay with providing your Acked-by? That's all up to Mathias, I'll defer to him here :) thanks,

Re: [PATCH v10 8/9] usb: xhci: Add NVIDIA Tegra XUSB controller driver

Hi Mathias, Greg, Due to the various dependencies within the series, I'd prefer this to go via the Tegra tree. Would you be okay with providing your Acked-by? Thanks, Thierry On Fri, Mar 04, 2016 at 05:19:38PM +0100, Thierry Reding wrote: > From: Thierry Reding > > Add

Re: [PATCH v10 4/9] phy: Add Tegra XUSB pad controller support

Hi Kishon, The dependencies within this series somewhat complicated, so I'd prefer to take it all via one tree. Would you be willing to give an Acked-by on this patch? Thierry On Fri, Mar 04, 2016 at 05:19:34PM +0100, Thierry Reding wrote: > From: Thierry Reding > > Add a

Re: [RFC] Create an audit record of USB specific details

On Mon, 2016-04-04 at 14:53 -0700, Greg KH wrote: > On Mon, Apr 04, 2016 at 02:48:43PM -0700, Greg KH wrote: > > On Mon, Apr 04, 2016 at 05:33:10PM -0400, Steve Grubb wrote: > > > On Monday, April 04, 2016 05:56:26 AM Greg KH wrote: > > > > On Mon, Apr 04, 2016 at 12:02:42AM -0400, wmealing wrote:

Re: [PATCH v7 3/3] usb: otg-fsm: Prevent build warning "VDBG" redefined

Peter, On 05/04/16 11:52, Peter Chen wrote: > On Thu, Mar 31, 2016 at 12:41:19PM +0300, Roger Quadros wrote: >> If usb/otg-fsm.h and usb/composite.h are included together >> then it results in the build warning [1]. >> >> Prevent that by using dev_vdbg() instead. >> > > After considering it

Re: [PATCH 1/2] HID: Use multitouch driver for Type Covers

On Sat, 2015-12-19 at 10:34 +0900, Akihiko Odaki wrote: > No, it doesn't work. According to: https://github.com/jimdigriz/debian-mssp4 Running "kbd_mode -u" afterwards would fix the Caps-Lock key not working. I have no idea what the wider consequence of this would be though[1]. Anything we can

[PATCH 1/8] usb: dwc3: gadget: rename busy/free_slot to trb_enqueue/dequeue

This makes it clear that we're dealing with a queue of TRBs. No functional changes. While at that, also rename start_slot to first_trb_index for similar reasons. Signed-off-by: Felipe Balbi --- drivers/usb/dwc3/core.h | 10 +- drivers/usb/dwc3/ep0.c|

[PATCH 8/8] usb: dwc3: gadget: remove newline from trace

trace already adds a newline character for us, we don't need to do it ourselves. Signed-off-by: Felipe Balbi --- drivers/usb/dwc3/gadget.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c

[PATCH 2/8] usb: dwc3: core: document struct dwc3_request

No functional changes. Merely adding useful documentation for future readers. Signed-off-by: Felipe Balbi --- drivers/usb/dwc3/core.h | 13 + 1 file changed, 13 insertions(+) diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h index

[PATCH 3/8] usb: dwc3: switch trb enqueue/dequeue and first_trb_index to u8

We *know* that we have 1 PAGE (4096 bytes) for our TRB poll. We also know the size of each TRB and know that we can fit 256 of them in one PAGE. By using a u8 type we can make sure that: enqueue++ % 256; gets optimized to an increment only. Signed-off-by: Felipe Balbi

[PATCH 5/8] usb: dwc3: gadget: add trb enqueue/dequeue helpers

Add three little helpers which will aid in making the code slightly easier to read. One helper increments enqueue pointer, another increments dequeue pointer and the last one tests if we're dealing with the last TRB. Signed-off-by: Felipe Balbi ---

[PATCH 7/8] usb: dwc3: gadget: use link TRB for all endpoint types

instead of limiting link TRB only to Isoc endpoints, let's use it for all endpoint types, this way we are more likely to transfer more data before a XferComplete event. Signed-off-by: Felipe Balbi --- here I still have a question if I should the

[PATCH 6/8] usb: dwc3: gadget: move % operation to increment helpers

By moving our % DWC3_NUM_TRB operation to the increment helpers, the rest of the driver can be simplified. It's also a good practice to make sure we will have a single place dealing with details about how to increment our enqueue and dequeue pointers. Signed-off-by: Felipe Balbi

[PATCH 4/8] usb: dwc3: get rid of DWC3_TRB_MASK

instead of using a bitwise and, let's rely on the % operator since that's a lot more clear. Also, GCC will optimize % 256 to nothing anyway. Signed-off-by: Felipe Balbi --- drivers/usb/dwc3/core.h | 1 - drivers/usb/dwc3/gadget.c | 14 +++--- 2 files

[PATCH 0/8] usb: dwc3: trb queue rework

Hi, with these patches we can use our TRB queue as a ring for all transfer types (except for control transfers ;-) So far, I have lightly tested these changes with g_mass_storage only. I will, certainly, run more tests and leave testusb running for a couple days before getting these upstream,

[PATCH] usb: dwc3: omap: drop dma_mask configuration

The DWC3 OMAP driver supports DT-boot only, as result dma_mask will be always configured properly from DT - of_platform_device_create_pdata()->of_dma_configure(). More over, dwc3-omap.c can be built as module and in this case it's unsafe to assign local variable as dma_mask. Hence, remove

RE: EXT :Re: [RFC] Create an audit record of USB specific details

Wade, Wouldn't this imply that every time the system is booted and the PCI bus for example is enumerated and all of the devices are created that all of those activities generate audit events? That sounds less than desiriable. Does this imply that the audit subsystem should maintain a

Re: [PATCH 2/6] usb: dwc3: omap: don't access DMA bits directly

Hi, Grygorii Strashko writes: > On 04/05/2016 01:29 PM, Felipe Balbi wrote: >> Grygorii Strashko writes: >>> On 04/05/2016 08:51 AM, Felipe Balbi wrote: Grygorii Strashko writes: > On 04/02/2016 11:28 AM,

Re: [PATCH 2/6] usb: dwc3: omap: don't access DMA bits directly

On 04/05/2016 01:29 PM, Felipe Balbi wrote: > Grygorii Strashko writes: >> On 04/05/2016 08:51 AM, Felipe Balbi wrote: >>> Grygorii Strashko writes: On 04/02/2016 11:28 AM, Felipe Balbi wrote: > Instead of having a static global just

Re: [PATCH v9 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

On 5 April 2016 at 17:43, Peter Chen wrote: > On Tue, Apr 05, 2016 at 05:34:02PM +0800, Baolin Wang wrote: >> On 5 April 2016 at 16:12, Peter Chen wrote: >> > On Tue, Apr 05, 2016 at 03:54:31PM +0800, Baolin Wang wrote: >> >> Hi Peter, >> >> >> >> On

ADMtek ADM8511 "Pegasus II" USB Ethernet causes oops

Hello, I have this (rather old) USB ethernet device but I cannot use it because it crashes my machine. Simply plugging in the adapter and causing some traffic (pinging the gateway will do) causes an oops. With older kernels (3.10-3.19) this was generally nearly instant. With the current

Re: [PATCH 2/6] usb: dwc3: omap: don't access DMA bits directly

Grygorii Strashko writes: > On 04/05/2016 08:51 AM, Felipe Balbi wrote: >> Grygorii Strashko writes: >>> On 04/02/2016 11:28 AM, Felipe Balbi wrote: Instead of having a static global just for initializing dma_mask directly, let's use

Re: [PATCH v9 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

On Tue, Apr 05, 2016 at 05:34:02PM +0800, Baolin Wang wrote: > On 5 April 2016 at 16:12, Peter Chen wrote: > > On Tue, Apr 05, 2016 at 03:54:31PM +0800, Baolin Wang wrote: > >> Hi Peter, > >> > >> On 5 April 2016 at 14:46, Peter Chen wrote: > >> > >

Re: [PATCH v9 1/4] gadget: Introduce the usb charger framework

On 5 April 2016 at 15:56, Peter Chen wrote: > On Fri, Apr 01, 2016 at 03:21:49PM +0800, Baolin Wang wrote: >> + >> +int devm_usb_charger_register(struct device *dev, >> + struct usb_charger *uchger) >> +{ >> + struct usb_charger **ptr; >> +

Re: [PATCH 1/3] usb: core: add power sequence for USB devices

On Mon, Mar 14, 2016 at 6:42 PM, Peter Chen wrote: > On Sat, Mar 05, 2016 at 03:10:11PM +0100, Andrew Lunn wrote: >> > So, would you like to accept the generic solution like below: >> > >> > - Create a generic power sequence driver, and it will be probed >> > according to

Re: [PATCH v9 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

On 5 April 2016 at 16:12, Peter Chen wrote: > On Tue, Apr 05, 2016 at 03:54:31PM +0800, Baolin Wang wrote: >> Hi Peter, >> >> On 5 April 2016 at 14:46, Peter Chen wrote: >> > >> > We are thinking USB charger framework for Freescale i.mx SoC series,

Re: [PATCH 2/6] usb: dwc3: omap: don't access DMA bits directly

On 04/05/2016 08:51 AM, Felipe Balbi wrote: > Grygorii Strashko writes: >> On 04/02/2016 11:28 AM, Felipe Balbi wrote: >>> Instead of having a static global just for >>> initializing dma_mask directly, let's use >>> dma_coerce_mask_and_coherent() for that. >>> >>>

[PATCH/RFC 4/5] usb: renesas_usbhs: change arguments of dma_map_ctrl()

In near the future, since usbhsg_dma_map_ctrl() needs DMA device structure, this patch changes arguments of dma_map_ctrl() to give such data. (This patch is only change the argument.) Signed-off-by: Yoshihiro Shimoda --- drivers/usb/renesas_usbhs/fifo.c |

[PATCH/RFC 5/5] usb: renesas_usbhs: use usb_gadget_{un}map_request_by_dev() for IPMMU

The previous code could use the first USB-DMAC with IPMMU if iommus property was set into this device node. However, in this case, it could not control the second USB-DMAC with IPMMU because a parameter of IPMMU (micro-TLB id) is different with each USB-DMAC. So, this patch uses the

[PATCH/RFC 1/5] usb: gadget: udc: core: Fix argument of dev_err() in usb_gadget_map_request()

The argument of dev_err() in usb_gadget_map_request() should be dev instead of >dev. Fixes: 7ace8fc ("usb: gadget: udc: core: Fix argument of dma_map_single for IOMMU") Cc: # v4.3+ Signed-off-by: Yoshihiro Shimoda ---

[PATCH/RFC 2/5] usb: gadget: udc: core: add usb_gadget_{un}map_request_by_dev()

If the following environment, the first argument of DMA API should be set to a DMAC's device structure, not a udc controller's one. - A udc controller needs an external DMAC device (like a DMA Engine). - The external DMAC enables IOMMU. So, this patch add usb_gadget_{un}map_request_by_dev() API

[PATCH/RFC 3/5] usb: renesas_usbhs: change function call orfer in usbhsf_dma_prepare_push()

In near the future, since usbhsf_dma_{un}map() will use the "fifo" data, this patch changes function call orfer in usbhsf_dma_prepare_push(). Signed-off-by: Yoshihiro Shimoda --- drivers/usb/renesas_usbhs/fifo.c | 12 ++-- 1 file changed, 6

[PATCH/RFC 0/5] usb: gadget: add new APIs of udc-core and modify renesas_usbhs for IPMMU

This patch set is based on the latest Felipe's usb.git / testing/next branch. (commit id = eac6b9922641f88a7da87a145d6ad9bed706c9ec) I'm not sure this is a right way for using IOMMU driver on udc driver. So, I marked this patch set as RFC :) Yoshihiro Shimoda (5): usb: gadget: udc: core: Fix

Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

Hi! > It would have the same downsides as in case of having r, g and b in > separate attributes, i.e. - problems with setting LED colour in > a consistent way. This way LED blinking in whatever colour couldn't > be supported reliably. It was one of your primary rationale standing

Re: [PATCH v7 3/3] usb: otg-fsm: Prevent build warning "VDBG" redefined

On Thu, Mar 31, 2016 at 12:41:19PM +0300, Roger Quadros wrote: > If usb/otg-fsm.h and usb/composite.h are included together > then it results in the build warning [1]. > > Prevent that by using dev_vdbg() instead. > After considering it more, I think it may not be a good solution that we delete

raid 5 creation fails on usb3 connected drives kernel 4.4.x, 4.5

SETUP: i7 16GB Computer. 1 x PCI-x USB3 adaptor card (i think uses xhci-hcd)04:00.0 USB controller: Renesas Technology Corp. uPD720202 USB 3.0 Host Controller (rev 02) Kernel driver in use: xhci_hcd 2 x USB3 to dual SATA HDD docks. uses JMicron JMS56x Series controllers, uses uas.ko

Re: [RFC] Create an audit record of USB specific details

I'm reframing my use case as follows to try and better explain the situation I am trying to track. It might seem that I am duplicating existing functionality, rather I am trying to augment functionality that seems to be unavailable.Replication of existing functionality is not my intention.

Re: [PATCH v9 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

On Tue, Apr 05, 2016 at 03:54:31PM +0800, Baolin Wang wrote: > Hi Peter, > > On 5 April 2016 at 14:46, Peter Chen wrote: > > > > We are thinking USB charger framework for Freescale i.mx SoC series, > > since our internal framework is not good enough. > > So I have more

Re: [PATCH v9 1/4] gadget: Introduce the usb charger framework

On Fri, Apr 01, 2016 at 03:21:49PM +0800, Baolin Wang wrote: > + > +int devm_usb_charger_register(struct device *dev, > + struct usb_charger *uchger) > +{ > + struct usb_charger **ptr; > + int ret; > + > + ptr = devres_alloc(devm_uchger_dev_unreg,

Re: [PATCH v9 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

Hi Peter, On 5 April 2016 at 14:46, Peter Chen wrote: > > We are thinking USB charger framework for Freescale i.mx SoC series, > since our internal framework is not good enough. > So I have more questions for your framework since there are many > different USB charger

Re: [PATCH v9 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

On Fri, Apr 01, 2016 at 03:21:48PM +0800, Baolin Wang wrote: > Currently the Linux kernel does not provide any standard integration of this > feature that integrates the USB subsystem with the system power regulation > provided by PMICs meaning that either vendors must add this in their kernels >

RE: [PATCH] usb: gadget: udc-core: remove manual dma configuration

Hi, > From: Grygorii Strashko [mailto:grygorii.stras...@ti.com] > Sent: Monday, April 04, 2016 8:32 PM > > Since commit 7ace8fc8219e ("usb: gadget: udc: core: Fix argument of > dma_map_single for IOMMU") it is not necessary to configure DMA for > usb_gadget device manually, because all DMA