On 3/2/16, Sedat Dilek wrote:
> On 3/1/16, Alan Stern wrote:
>> On Tue, 1 Mar 2016, Sedat Dilek wrote:
>>
>>> On Tue, Oct 13, 2015 at 2:57 AM, Steven Rostedt
>>> wrote:
>>> > On Sat, 3 Oct 2015 12:05:42 +0200
>>> > Sedat Dilek wrote:
>>> >
>>> >> So, at the beginning... dunno WTF is causing the
On Wed, 2 Mar 2016, Sedat Dilek wrote:
>
> static bool start_flush_work(struct work_struct *work, struct wq_barrier
> *barr)
> {
> struct worker *worker = NULL;
> struct worker_pool *pool;
> struct pool_workqueue *pwq;
>
> might_sleep();
>
> local_irq_dis
On Tue, Mar 01, 2016 at 02:36:32PM +0100, Bjørn Mork wrote:
> The MC74xx and EM74xx modules use different IDs by default, according
> to the Lenovo EM7455 driver for Windows.
>
> Cc:
> Signed-off-by: Bjørn Mork
Now applied, thanks.
Johan
--
To unsubscribe from this list: send the line "unsubsc
On 03/01/2016 10:41 PM, Greg KH wrote:
On Tue, Mar 01, 2016 at 10:29:31PM +0100, Heiner Kallweit wrote:
Document the color extension in Documentation/leds/leds-class.txt
Signed-off-by: Heiner Kallweit
---
v2:
- introduced to patch series
v3:
- document extension in more detail
v4:
- Better exp
> -Original Message-
> From: Alan Stern [mailto:st...@rowland.harvard.edu]
> Sent: Monday, 29 February, 2016 16:30
> To: Dobrowolski, Robert
> Cc: linux-usb@vger.kernel.org; Andruszak, Adam ;
> Nyman, Mathias
> Subject: Re: [PATCH v1] usb: hcd: out of bounds access in for_each_companion
>
On 3/2/16, Jiri Kosina wrote:
> On Wed, 2 Mar 2016, Sedat Dilek wrote:
>>
>> static bool start_flush_work(struct work_struct *work, struct wq_barrier
>> *barr)
>> {
>> struct worker *worker = NULL;
>> struct worker_pool *pool;
>> struct pool_workqueue *pwq;
>>
>> mi
On Wed, Mar 2, 2016 at 3:17 AM, Simon Horman wrote:
> Make use of ARCH_RENESAS in place of ARCH_SHMOBILE.
>
> This is part of an ongoing process to migrate from ARCH_SHMOBILE to
> ARCH_RENESAS the motivation for which being that RENESAS seems to be a more
> appropriate name than SHMOBILE for the m
Add support for :
- UPort 1110 : 1 port RS-232 USB to Serial Hub.
- UPort 1130 : 1 port RS-422/485 USB to Serial Hub.
- UPort 1130I : 1 port RS-422/485 USB to Serial Hub with Isolation.
- UPort 1150 : 1 port RS-232/422/485 USB to Serial Hub.
- UPort 1150I : 1 port RS-232/422/485 USB to Serial H
On Wed, Mar 2, 2016 at 9:38 AM, Jacek Anaszewski
wrote:
> On 03/01/2016 10:41 PM, Greg KH wrote:
>>
>> On Tue, Mar 01, 2016 at 10:29:31PM +0100, Heiner Kallweit wrote:
>>>
>>> Document the color extension in Documentation/leds/leds-class.txt
>>>
>>> Signed-off-by: Heiner Kallweit
>>> ---
>>> v2:
We need to move the kfree() down a line so we don't dereference a freed
variable.
Fixes: 1b418a8fcbc0 ('target: Convert demo-mode only drivers to
target_alloc_session')
Signed-off-by: Dan Carpenter
diff --git a/drivers/usb/gadget/function/f_tcm.c
b/drivers/usb/gadget/function/f_tcm.c
index 727
Dan Carpenter writes:
> We need to move the kfree() down a line so we don't dereference a freed
> variable.
>
> Fixes: 1b418a8fcbc0 ('target: Convert demo-mode only drivers to
> target_alloc_session')
> Signed-off-by: Dan Carpenter
It's okay to take this via target:
Signed-off-by: Felipe Balbi
On 26.01.2016 14:58, Lu Baolu wrote:
In case of endpoint stall, software is able to detect the situation
by reading DCCTRL.HIT or DCCTRL.HOT bits. DbC follows the normal USB
framework to handle endpoint stall. When software detects endpoint
stall situation, it should wait until endpoint is recove
Hi,
Mathias Nyman writes:
> [ text/plain ]
> On 26.01.2016 14:58, Lu Baolu wrote:
>> In case of endpoint stall, software is able to detect the situation
>> by reading DCCTRL.HIT or DCCTRL.HOT bits. DbC follows the normal USB
>> framework to handle endpoint stall. When software detects endpoint
>
On 3/1/16, Peter Zijlstra wrote:
> On Tue, Mar 01, 2016 at 10:07:40AM -0500, Steven Rostedt wrote:
>> On Tue, 1 Mar 2016 11:05:42 +0100
>> Sedat Dilek wrote:
>>
>>
>> > [ FACT #3: TEST-CASE #2 ]
>> >
>> > The most reliable test-case is to simply unplug my external Logitech
>> > USB mouse - saw th
On Wed, 2 Mar 2016, Dobrowolski, Robert wrote:
> > -Original Message-
> > From: Alan Stern [mailto:st...@rowland.harvard.edu]
> > Sent: Monday, 29 February, 2016 16:30
> > To: Dobrowolski, Robert
> > Cc: linux-usb@vger.kernel.org; Andruszak, Adam ;
> > Nyman, Mathias
> > Subject: Re: [PA
On Wed, Mar 02, 2016 at 04:00:49PM +0100, Sedat Dilek wrote:
> >
> > Right, most odd. Sedat, could you provide objdump -D of the relevant
> > sections of vmlinux ?
> >
>
> Can you give some clear instructions - for what shall I look for in special?
objdump -D vmlinux | awk '/<[^>]*>:$/ { p=0; } /
This series addresses a couple of similar warnings in USB
host and phy drivers. In each case, there is a mismatch between
the references to some functions and the #ifdef hiding those
functions (if any).
The series gets rid of all those #ifdes and instead changes
the drivers that don't already get
The ehci-atmel driver uses #ifdef to check for CONFIG_PM, but then
uses SIMPLE_DEV_PM_OPS, which leaves the references out when
CONFIG_PM_SLEEP is not defined, so we get a warning with
PM=y && PM_SLEEP=n:
drivers/usb/host/ehci-atmel.c:189:12: error: 'ehci_atmel_drv_suspend' defined
but not used [
The dm816x USB PHY driver uses UNIVERSAL_DEV_PM_OPS to access
its suspend/resume functions, which causes a warning about
unused symbols when CONFIG_PM is disabled:
drivers/phy/phy-dm816x-usb.c:121:12: error: 'dm816x_usb_phy_runtime_suspend'
defined but not used [-Werror=unused-function]
drivers/p
There is no need to hide function declarations, and making
these visible to the SoC specific host drivers lets us
use __maybe_unused and IS_ENABLED() checks to control
their use, rather than having to use #ifdef to hide all
callers.
Signed-off-by: Arnd Bergmann
---
drivers/usb/host/ehci.h | 2 --
The ohci-at91 driver uses #ifdef to check for CONFIG_PM, but then
uses SIMPLE_DEV_PM_OPS, which leaves the references out when
CONFIG_PM_SLEEP is not defined, so we get a warning with
PM=y && PM_SLEEP=n:
drivers/usb/host/ohci-at91.c:587:1: error: 'ohci_hcd_at91_drv_suspend' defined
but not used [
The mediatek XHCI glue driver uses SET_SYSTEM_SLEEP_PM_OPS() to
conditionally set the correct suspend/resume options, and
also puts both the dev_pm_ops and the functions inside of
an #ifdef testing for CONFIG_PM_SLEEP, but those functions
then call other code that becomes unused:
drivers/usb/host/
The twl4030 USB PHY driver uses UNIVERSAL_DEV_PM_OPS to access
its suspend/resume functions, which causes a warning about
unused symbols when CONFIG_PM is disabled:
drivers/phy/phy-twl4030-usb.c:394:12: error: 'twl4030_usb_runtime_suspend'
defined but not used [-Werror=unused-function]
drivers/ph
Le 02/03/2016 16:24, Arnd Bergmann a écrit :
> The ohci-at91 driver uses #ifdef to check for CONFIG_PM, but then
> uses SIMPLE_DEV_PM_OPS, which leaves the references out when
> CONFIG_PM_SLEEP is not defined, so we get a warning with
> PM=y && PM_SLEEP=n:
>
> drivers/usb/host/ohci-at91.c:587:1: e
Le 02/03/2016 16:24, Arnd Bergmann a écrit :
> The ehci-atmel driver uses #ifdef to check for CONFIG_PM, but then
> uses SIMPLE_DEV_PM_OPS, which leaves the references out when
> CONFIG_PM_SLEEP is not defined, so we get a warning with
> PM=y && PM_SLEEP=n:
>
> drivers/usb/host/ehci-atmel.c:189:12
On 3/2/16, Peter Zijlstra wrote:
> On Wed, Mar 02, 2016 at 04:00:49PM +0100, Sedat Dilek wrote:
>> >
>> > Right, most odd. Sedat, could you provide objdump -D of the relevant
>> > sections of vmlinux ?
>> >
>>
>> Can you give some clear instructions - for what shall I look for in
>> special?
>
> o
On Wed, 2 Mar 2016, Arnd Bergmann wrote:
> There is no need to hide function declarations, and making
> these visible to the SoC specific host drivers lets us
> use __maybe_unused and IS_ENABLED() checks to control
> their use, rather than having to use #ifdef to hide all
> callers.
>
> Signed-of
[ Resend with reply all, instead of just "reply" ]
On Wed, 2 Mar 2016 16:53:36 +0100
Sedat Dilek wrote:
> 8110f3f0 :
> 8110f3f0: 55 push %rbp
> 8110f3f1: 48 89 e5mov%rsp,%rbp
> 8110f3f4: 41 57
Hello,
(cc'ing Jan)
On Fri, Feb 26, 2016 at 02:19:20PM +0800, Peter Chen wrote:
> On Thu, Feb 25, 2016 at 05:01:12PM -0500, Tejun Heo wrote:
> > Hello, Peter.
> >
> > On Wed, Feb 24, 2016 at 03:24:30PM +0800, Peter Chen wrote:
> > > > You might want to complain to the block-layer people about th
On Tue, 1 Mar 2016, Daniel Fraga wrote:
> On Tue, 1 Mar 2016 17:15:56 -0500 (EST)
> Alan Stern wrote:
>
> > Don't worry about the Elan driver. Instead, let's see if this patch
> > fixes the problem.
>
> Yes, this patch fixed the problem. I can suspend and resume
> without those repeated
On 3/2/16, Sedat Dilek wrote:
> On 3/2/16, Steven Rostedt wrote:
>>
>> [ Resend with reply all, instead of just "reply" ]
>>
>> On Wed, 2 Mar 2016 16:53:36 +0100
>> Sedat Dilek wrote:
>>
>>> 8110f3f0 :
>>> 8110f3f0: 55 push %rbp
>>> 8110f3f1: 48
On 3/2/16, Sedat Dilek wrote:
> On 3/2/16, Sedat Dilek wrote:
>> On 3/2/16, Steven Rostedt wrote:
>>>
>>> [ Resend with reply all, instead of just "reply" ]
>>>
>>> On Wed, 2 Mar 2016 16:53:36 +0100
>>> Sedat Dilek wrote:
>>>
8110f3f0 :
8110f3f0: 55
On Wed, Mar 02, 2016 at 04:53:36PM +0100, Sedat Dilek wrote:
> 8110f570 :
> 8110f570: 55 push %rbp
> 8110f571: 48 89 e5mov%rsp,%rbp
> 8110f574: 41 57 push %r15
> 8110f576: 41 56
On Wed, 2 Mar 2016 17:24:12 +0100
Peter Zijlstra wrote:
> On Wed, Mar 02, 2016 at 04:53:36PM +0100, Sedat Dilek wrote:
> > 8110f570 :
> > 8110f570: 55 push %rbp
> > 8110f571: 48 89 e5mov%rsp,%rbp
> > 8110f574: 41 57
On 3/2/16, Peter Zijlstra wrote:
> On Wed, Mar 02, 2016 at 04:53:36PM +0100, Sedat Dilek wrote:
>> 8110f570 :
>> 8110f570:55 push %rbp
>> 8110f571:48 89 e5mov%rsp,%rbp
>> 8110f574:41 57 push
On Wed, Mar 02, 2016 at 11:35:35AM -0500, Steven Rostedt wrote:
> On Wed, 2 Mar 2016 17:24:12 +0100
> Peter Zijlstra wrote:
>
> > On Wed, Mar 02, 2016 at 04:53:36PM +0100, Sedat Dilek wrote:
> > > 8110f570 :
> > > 8110f570: 55 push %rbp
> > > 8110f57
On 3/2/16, Sedat Dilek wrote:
> On 3/2/16, Peter Zijlstra wrote:
>> On Wed, Mar 02, 2016 at 04:53:36PM +0100, Sedat Dilek wrote:
>>> 8110f570 :
>>> 8110f570: 55 push %rbp
>>> 8110f571: 48 89 e5mov%rsp,%rbp
>>> 8110f574
On Mon, Feb 29, 2016 at 3:20 AM, Petr Kulhavy wrote:
>
>
> On 26.02.2016 15:23, Bin Liu wrote:
>>
>> Hi,
>>
>> On Fri, Feb 26, 2016 at 10:29:12AM +0100, Petr Kulhavy wrote:
>>>
>>> On 26.02.2016 04:15, Bin Liu wrote:
On Thu, Feb 25, 2016 at 01:04:13PM +0100, Petr Kulhavy wrote:
On Wed, Feb 24, 2016 at 04:26:13PM +0100, Petr Kulhavy wrote:
> DT binding for the TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver.
>
> Signed-off-by: Petr Kulhavy
> ---
> v1:
>
> v2:
> - using standard properties "dr_mode", "mentor,power", "mentor,num-eps",
> "mentor,multipoint", "mentor,ram-bit
On Wed, 2 Mar 2016, Oliver Neukum wrote:
On Tue, 2016-03-01 at 09:54 -0800, amarb...@apl.washington.edu wrote:
From: Aaron Marburg
The USOPTL4-4P and USOPTL4-2P USB-to-quad/dual RS-485/422 hubs use the
Moschip 7840/7820. For correct operation in RS-485, the chip must be
configured in “RS-48
Document the color extension in Documentation/leds/leds-class.txt
Signed-off-by: Heiner Kallweit
---
v2:
- introduced to patch series
v3:
- document extension in more detail
v4:
- Better explain why flag LED_SET_HUE_SAT is needed
v5:
- no changes
v6:
- add docu for this feature to Documentation/A
This gadget uses a bmAttributes and MaxPower that requires the USB bus to be
powered from the host, which is not correct because this configuration is device
specific, not a USB-MIDI requirement.
This patch adds two modules parameters, bmAttributes and MaxPower, that allows
the user to set those f
Since f_midi_transmit is called by both ALSA and USB frameworks, it can
potentially cause a race condition between both calls. This is bad because the
way f_midi_transmit is implemented can't handle concurrent calls. This is due
to the fact that the usb request fifo looks for the next element and o
Signed-off-by: Felipe F. Tonello
---
drivers/usb/gadget/function/f_midi.c | 77 +++-
1 file changed, 40 insertions(+), 37 deletions(-)
diff --git a/drivers/usb/gadget/function/f_midi.c
b/drivers/usb/gadget/function/f_midi.c
index 8475e3dc82d4..9a9e6112e224 100644
Signed-off-by: Felipe F. Tonello
---
drivers/usb/gadget/function/f_midi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/gadget/function/f_midi.c
b/drivers/usb/gadget/function/f_midi.c
index 9a9e6112e224..5c7f5c780fda 100644
--- a/drivers/usb/gadget/function/f_midi.c
+++ b/dr
This refactor results in a cleaner state machine code and as a result fixed a
bug when packaging a USB-MIDI packet right after a non-conformant MIDI byte
stream.
Signed-off-by: Felipe F. Tonello
---
drivers/usb/gadget/function/f_midi.c | 204 ++-
1 file changed,
Patches are pretty much self-described.
Patch 1 is revised from comments.
Patch 2 is a bug fix.
Felipe F. Tonello (5):
usb: gadget: f_midi: refactor state machine
usb: gadget: f_midi: added spinlock on transmit function
usb: gadget: gmidi: remove bus powered requirement on bmAttributes
us
你的老朋友邀你来Q群:343257759
Based on the proposed RGB LED core extension the thingm driver was
changed to make use of this extension. It allows to simplify
the code a lot. For now primary purpose of this patch is to facilitate
testing of the RGB LED core extension.
I didn't find a way to split the patch into smaller parts as
Felipe F. Tonello wrote:
> This refactor results in a cleaner state machine code
It increases the number of states, and now juggles two state variables.
I cannot agree to it being cleaner.
> and as a result fixed a bug when packaging a USB-MIDI packet right after
> a non-conformant MIDI byte stre
On Mon, Feb 22, 2016 at 4:07 PM, Bjorn Andersson
wrote:
> On Mon 22 Feb 02:03 PST 2016, Srinivas Kandagatla wrote:
>
>>
>>
>> On 22/02/16 05:32, Bjorn Andersson wrote:
>> >On certain platforms (e.g. ARM64) the dma_ops needs to be explicitly set
>> >to be able to do DMA allocations, so use the of_d
Hi Felipe,
Oops, I completely forgot this patch.
Would you review this patch? Or should I resend it?
I confirmed that this patch could be applied on your latest testing/fixes
branch.
Best regards,
Yoshihiro Shimoda
> -Original Message-
> From: Yoshihiro Shimoda
> Sent: Friday, December
Direct access to clock control registers can be safely removed, the
task of clock management is done by platform clock driver based on
common clock framework.
Signed-off-by: Vladimir Zapolskiy
---
drivers/usb/host/ohci-nxp.c | 18 --
1 file changed, 18 deletions(-)
diff --git a/
LPC32xx common clock framework driver correctly manages parent clocks
of USB OHCI clock, so there is no need to manually enable and
disable them from the driver, which now depends only on a single USB
host clock.
Signed-off-by: Vladimir Zapolskiy
---
drivers/usb/host/ohci-nxp.c | 62
The change removes direct clock management from NXP LPC32xx USB OHCI
driver done by accessing platform clock control registers, also
after switching the platform to a common clock framework there is
no need to look for and enable all parent clocks, clock management
is delegated to the CCF driver.
LPC32xx common clock framework driver correctly manages parent clocks
of USB device clock, so there is no need to manually enable and
disable them from the driver, which now depends only on a single USB
device clock.
Signed-off-by: Vladimir Zapolskiy
---
drivers/usb/gadget/udc/lpc32xx_udc.c | 64
The change removes direct clock management from NXP LPC32xx USB UDC
driver done by accessing platform clock control registers, also
after switching the platform to a common clock framework there is
no need to look for and enable all parent clocks, clock management
is delegated to the CCF driver.
T
The driver requires to prepare/unprepare clocks to work properly on a
platform with enabled common clock framework, otherwise unprepared
clocks are not enabled:
WARNING: CPU: 0 PID: 1 at drivers/clk/clk.c:728 clk_core_enable+0x2c/0xf0()
Modules linked in:
CPU: 0 PID: 1 Comm: swapper No
Direct access to clock control registers can be safely removed, the
task of clock management is done by platform clock driver based on
common clock framework.
Signed-off-by: Vladimir Zapolskiy
---
drivers/usb/gadget/udc/lpc32xx_udc.c | 29 -
1 file changed, 29 deletio
On 03/02/2016 08:58 PM, Mathias Nyman wrote:
> On 26.01.2016 14:58, Lu Baolu wrote:
>> In case of endpoint stall, software is able to detect the situation
>> by reading DCCTRL.HIT or DCCTRL.HOT bits. DbC follows the normal USB
>> framework to handle endpoint stall. When software detects endpoint
On 03/02/2016 08:58 PM, Felipe Balbi wrote:
> Hi,
>
> Mathias Nyman writes:
>> [ text/plain ]
>> On 26.01.2016 14:58, Lu Baolu wrote:
>>> In case of endpoint stall, software is able to detect the situation
>>> by reading DCCTRL.HIT or DCCTRL.HOT bits. DbC follows the normal USB
>>> framework to
Several Intel PCHs and SOCs have an internal mux that is used to
share one USB port between device controller and host controller.
The mux is handled through the Dual Role Configuration Register.
Signed-off-by: Heikki Krogerus
Signed-off-by: Lu Baolu
Signed-off-by: Wu Hao
Reviewed-by: Felipe Ba
Some Intel platforms have an USB port mux controlled by GPIOs.
There's a single ACPI platform device that provides both USB ID
extcon device and a USB port mux device. This MFD driver will
split the 2 devices for their respective drivers.
Signed-off-by: Lu Baolu
Suggested-by: David Cohen
Reviewe
In some Intel platforms, a single usb port is shared between USB host
and device controllers. The shared port is under control of a switch
which is defined in the Intel vendor defined extended capability for
xHCI.
This patch adds the support to detect and create the platform device
for the port mu
Intel SOC chips are featured with USB dual role. The host role is
provided by Intel xHCI IP, and the gadget role is provided by IP
from designware. Tablet platform designs always share a single
port for both host and gadget controllers. There is a mux to
switch the port to the right controller acco
Several Intel PCHs and SOCs have an internal mux that is used to
share one USB port between device controller and host controller.
A usb port mux could be abstracted as the following elements:
1) mux state: HOST or PERIPHERAL;
2) an extcon cable which triggers the change of mux state between
HO
In some Intel platforms, a single usb port is shared between USB host
and device controller. The shared port is under control of GPIO pins.
This patch adds the support for USB GPIO controlled port mux.
Signed-off-by: David Cohen
Signed-off-by: Lu Baolu
Reviewed-by: Heikki Krogerus
Reviewed-by:
This is needed to handle the GPIO connected USB ID pin found on
Intel Baytrail devices.
Signed-off-by: Lu Baolu
Reviewed-by: Felipe Balbi
---
drivers/extcon/extcon-usb-gpio.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/extcon/extcon-usb-gpio.c b/drivers/extcon/extcon-usb-
GPIO resource could be retrieved through APCI as well.
Signed-off-by: Lu Baolu
Reviewed-by: Felipe Balbi
---
drivers/extcon/extcon-usb-gpio.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/extcon/extcon-usb-gpio.c b/drivers/extcon/extcon-usb-gpio.c
index af9c8b0..
Hell Lu,
On 2016년 03월 03일 15:37, Lu Baolu wrote:
> This is needed to handle the GPIO connected USB ID pin found on
> Intel Baytrail devices.
>
> Signed-off-by: Lu Baolu
> Reviewed-by: Felipe Balbi
> ---
> drivers/extcon/extcon-usb-gpio.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff
Hi Lu,
On 2016년 03월 03일 15:37, Lu Baolu wrote:
> GPIO resource could be retrieved through APCI as well.
>
> Signed-off-by: Lu Baolu
> Reviewed-by: Felipe Balbi
> ---
> drivers/extcon/extcon-usb-gpio.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/extcon/ex
On 03/03/2016 03:24 PM, Chanwoo Choi wrote:
> Hell Lu,
>
> On 2016년 03월 03일 15:37, Lu Baolu wrote:
>> This is needed to handle the GPIO connected USB ID pin found on
>> Intel Baytrail devices.
>>
>> Signed-off-by: Lu Baolu
>> Reviewed-by: Felipe Balbi
>> ---
>> drivers/extcon/extcon-usb-gpio.c
On 03/03/2016 03:24 PM, Chanwoo Choi wrote:
> Hi Lu,
>
> On 2016년 03월 03일 15:37, Lu Baolu wrote:
>> GPIO resource could be retrieved through APCI as well.
>>
>> Signed-off-by: Lu Baolu
>> Reviewed-by: Felipe Balbi
>> ---
>> drivers/extcon/extcon-usb-gpio.c | 3 ++-
>> 1 file changed, 2 inserti
73 matches
Mail list logo
