Hello,
This is a resend of the patches that were not picked from the series
"[PATCH 00/27] Export I2C and OF module aliases in missing drivers" [0]
posted about a month ago.
The patches have no dependencies and can be picked individually by the
relevant maintainer.
I preferred to resend instead
The I2C core always reports the MODALIAS uevent as "i2c:
---
drivers/usb/phy/phy-isp1301.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/phy/phy-isp1301.c b/drivers/usb/phy/phy-isp1301.c
index 8a55b37d1a02..db68156568e6 100644
--- a/drivers/usb/phy/phy-isp1301.c
+++ b/drivers/u
On 25.08.2015 14:47, Marek Szyprowski wrote:
> Hello,
>
> On 2015-08-21 14:44, Kishon Vijay Abraham I wrote:
>> On Friday 21 August 2015 06:08 PM, Marek Szyprowski wrote:
>>> Exynos USB2 PHY has separate power supply, which is usually provided by
>>> VBUS regulator. This patch adds support for it.
Hello,
On 2015-08-21 14:44, Kishon Vijay Abraham I wrote:
On Friday 21 August 2015 06:08 PM, Marek Szyprowski wrote:
Exynos USB2 PHY has separate power supply, which is usually provided by
VBUS regulator. This patch adds support for it. VBUS regulator is
optional, to keep compatibility with boa
On 21 August 2015 at 17:48, Daurnimator wrote:
> On 21 August 2015 at 17:39, Mathias Nyman wrote:
>> I can't directly see what would cause it. Only theory for now is if one
>> those changes left
>> some port change event uncleared, blocking port status change events and
>> thus maybe also
>>
Hi Greg
>
>This still doesn't apply at all, please work on sending the patch to
>yourself and seeing if you can add it to my usb-next git branch.
>
Sorry for the inconvenience to you
I think its problem with my email client for sending patch.
Now, i will make new patch against latest linux-next
On 08/21/2015 09:50 AM, Dmitry Torokhov wrote:
Hi Laura,
On Mon, Aug 10, 2015 at 05:26:12PM -0700, Laura Abbott wrote:
v2: Created a proper queue for events instead of just dropping them
How long does it take for the queue to exhaust your memory if you keep
bombarding the driver with requests
On Mon, Aug 24, 2015 at 09:40:04PM +0530, Sanchayan Maity wrote:
> Hello,
>
> I am working on Freescale Vybrid which is a Cortex A5 based SoC,
> with a Chipidea based USB controller and a Sigmatel Phy or some-
> thing if my memory serves me right. We are currently in the process
> of implementing
On Mon, Aug 24, 2015 at 02:17:08PM -0400, Alan Stern wrote:
> On Mon, 24 Aug 2015, Felipe Balbi wrote:
>
> > > Maybe we should add a vendor-specific control request to gadget Zero so
> > > that the host can tell the gadget what the transfer size will be.
> >
> > I proposed that many months ago an
On Mon, Aug 24, 2015 at 10:53:50AM -0500, Felipe Balbi wrote:
> On Mon, Aug 24, 2015 at 10:51:04AM -0400, Alan Stern wrote:
> > On Mon, 24 Aug 2015, Peter Chen wrote:
> >
> > > Thanks, that's much clear.
> > >
> > > At udc driver:
> > >
> > > __set_halt(struct usb_ep *ep, int value, bool may_fai
Fix the Sparse warning:
message.c:1390:21: warning: symbol 'i' shadows an earlier one
message.c:1294:13: originally declared here
Signed-off-by: Kris Borer
---
drivers/usb/core/message.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
i
On 25.08.2015 08:30, John Youn wrote:
> On 8/18/2015 11:54 AM, Felipe Balbi wrote:
>> this driver has long ago became dwc2.ko with
>> both peripheral and host roles, there's no point
>> in keeping the old function names.
>>
>> Signed-off-by: Felipe Balbi
>> ---
>> arch/arm/mach-s3c64xx/mach-crag6
On 8/18/2015 11:54 AM, Felipe Balbi wrote:
> this driver has long ago became dwc2.ko with
> both peripheral and host roles, there's no point
> in keeping the old function names.
>
> Signed-off-by: Felipe Balbi
> ---
> arch/arm/mach-s3c64xx/mach-crag6410.c | 4 +-
> arch/arm/mach-s3c64xx/mach
Hello,
Just in case it faded from memory, here is why try2 did not get
included:
On Tue, 17 Mar 2015 19:33:21 -0500, Felipe Balbi wrote:
> On Tue, Mar 17, 2015 at 12:23:03PM -0700, John Youn wrote:
> > Can you hold off on merging this series until we get Yousaf's
> > latest changes reviewed and
On Sat, Aug 15, 2015 at 1:58 AM, Christoph Hellwig wrote:
> On Fri, Aug 14, 2015 at 05:52:44PM -0700, Duc Dang wrote:
>> The commit 08439fec26 "ext4: remove block_device_ejected" only causes
>> issue with ext4 and
>> trying reverting it helps our test passes with ext4.
>>
>> But how about the same
The kernel supports the device authorization because of wireless USB.
These is usable for wired USB devices, too.
These new interface authorization allows to enable or disable
individual interfaces instead a whole device.
If a deauthorized interface will be authorized so the driver probing must
be
Interfaces are allowed per default.
This can disabled or enabled (again) by writing 0 or 1 to
/sys/bus/usb/devices/usbX/interface_authorized_default
Signed-off-by: Stefan Koch
---
drivers/usb/core/hcd.c | 47 ++
drivers/usb/core/message.c | 1 +
i
The attribute authorized shows the authorization state for an interface.
Signed-off-by: Stefan Koch
---
include/linux/usb.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/usb.h b/include/linux/usb.h
index 447fe29..3deccab 100644
--- a/include/linux/usb.h
+++ b/include/linux/us
With this patch a flag instead of a variable
is used for the default device authorization.
Signed-off-by: Stefan Koch
---
drivers/usb/core/hcd.c | 31 +--
drivers/usb/core/usb.c | 2 +-
include/linux/usb/hcd.h | 16 +---
3 files changed, 31 insertions(+
Driver probings and interface claims get rejected
if an interface is not authorized.
Signed-off-by: Stefan Koch
---
drivers/usb/core/driver.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/usb/core/driver.c b/drivers/usb/core/driver.c
index 818369a..d542d43 100644
--- a/driv
This introduces an attribute for each interface to
authorize (1) or deauthorize (0) it:
/sys/bus/usb/devices/INTERFACE/authorized
Signed-off-by: Stefan Koch
---
drivers/usb/core/sysfs.c | 36
1 file changed, 36 insertions(+)
diff --git a/drivers/usb/core/sys
This part adds the documentation for the interface authorization.
Signed-off-by: Stefan Koch
---
Documentation/ABI/testing/sysfs-bus-usb | 20
Documentation/usb/authorization.txt | 31 +++
2 files changed, 51 insertions(+)
diff --git a/Docume
This patch introduces an interface authorization for USB devices.
The kernel supports a device authorization because of wireless USB.
But the new interface authorization allows to authorize or deauthorize
individual interfaces instead authorization or deauthorize a whole device.
Therefore the aut
Am Montag, den 17.08.2015, 09:34 -0700 schrieb Greg KH:
> On Sat, Aug 08, 2015 at 11:32:50AM +0200, Stefan Koch wrote:
> > The attribute authorized shows the authorization state for an interface.
> >
> > Signed-off-by: Stefan Koch
>
> This email bounces, so I have to rip this series out of the t
Eugene Shatokhin writes:
> The race may happen when a device (e.g. YOTA 4G LTE Modem) is
> unplugged while the system is downloading a large file from the Net.
>
> Hardware breakpoints and Kprobes with delays were used to confirm that
> the race does actually happen.
>
> The race is on skb_queue
After a few iterations of start/stop UVC camera streaming, the streaming
stops.
This patch adds 250us delay in the cppi channel abort path to let cppi
drain properly.
Using 50us delay seems to be too aggressive, some webcams are still
broken. 250us is the original value used in TI 3.2 kernel.
Si
The following problems found when investigating races in usbnet module
are fixed here:
1. EVENT_NO_RUNTIME_PM bit of dev->flags should be read before it is
cleared by "dev->flags = 0". Thanks to Oliver Neukum for spotting this
problem and providing a fix.
2. A race on on skb_queue between usbne
It is needed to check EVENT_NO_RUNTIME_PM bit of dev->flags in
usbnet_stop(), but its value should be read before it is cleared
when dev->flags is set to 0.
The problem was spotted and the fix was provided by
Oliver Neukum .
Signed-off-by: Eugene Shatokhin
---
drivers/net/usb/usbnet.c | 7 -
The race may happen when a device (e.g. YOTA 4G LTE Modem) is
unplugged while the system is downloading a large file from the Net.
Hardware breakpoints and Kprobes with delays were used to confirm that
the race does actually happen.
The race is on skb_queue ('next' pointer) between usbnet_stop()
On Mon, 24 Aug 2015 12:48:13 +0300, Mathias Nyman
wrote:
> Do the usb devices work normally after a successful boot?
> (no suspicious xhci entries in dmesg)
There are indeed some suspicious messages in my current dmesg:
$ dmesg | grep "[xeou]hci"
[2.115002] xhci_hcd :00:14.0: xHCI Host C
On Mon, 24 Aug 2015 10:15:52 +, David Laight
wrote:
> Probably worth determining which xhci controller hardware is being used.
I believe it is part of the CPU:
http://ark.intel.com/products/78866/Intel-Celeron-Processor-J1800-1M-Cache-up-to-2_58-GHz
(from the datasheet link, pardon the "(
From: Alan Stern
Date: Mon, 24 Aug 2015 14:06:15 -0400 (EDT)
> On Mon, 24 Aug 2015, David Miller wrote:
>> Atomic operations like clear_bit also will behave that way.
>
> Are you certain about that? I couldn't find any mention of it in
> Documentation/atomic_ops.txt.
>
> In theory, an architec
On Mon, 24 Aug 2015, Alan Stern wrote:
> On Mon, 24 Aug 2015, David Miller wrote:
>
> > From: Eugene Shatokhin
> > Date: Wed, 19 Aug 2015 14:59:01 +0300
> >
> > > So the following might be possible, although unlikely:
> > >
> > > CPU0 CPU1
> > > clear_bit: read dev
24.08.2015 20:43, David Miller пишет:
From: Eugene Shatokhin
Date: Wed, 19 Aug 2015 14:59:01 +0300
So the following might be possible, although unlikely:
CPU0 CPU1
clear_bit: read dev->flags
clear_bit: clear EVENT_RX_KILL in the read value
dev-
On Mon, 24 Aug 2015, Felipe Balbi wrote:
> > Maybe we should add a vendor-specific control request to gadget Zero so
> > that the host can tell the gadget what the transfer size will be.
>
> I proposed that many months ago and you were against it, remember ?
I believe you -- it sounds like the s
On Mon, 24 Aug 2015, David Miller wrote:
> From: Eugene Shatokhin
> Date: Wed, 19 Aug 2015 14:59:01 +0300
>
> > So the following might be possible, although unlikely:
> >
> > CPU0 CPU1
> > clear_bit: read dev->flags
> > clear_bit: clear EVENT_RX_KIL
From: Eugene Shatokhin
Date: Wed, 19 Aug 2015 14:59:01 +0300
> So the following might be possible, although unlikely:
>
> CPU0 CPU1
> clear_bit: read dev->flags
> clear_bit: clear EVENT_RX_KILL in the read value
>
> dev->flags=0;
>
>
On 08/18/2015 12:56 AM, Ivan T. Ivanov wrote:
> Right now even if driver failed to probe extcon framework will
> still deliver its VBUS and ID events, which will lead to random
> exception codes.
>
> Fix this by removing driver interest for VBUS and ID events when
> probe fail.
>
> Fixes: 591fc11
24.08.2015 16:29, Bjørn Mork пишет:
Eugene Shatokhin writes:
19.08.2015 15:31, Bjørn Mork пишет:
Eugene Shatokhin writes:
The problem is not in the reordering but rather in the fact that
"dev->flags = 0" is not necessarily atomic
w.r.t. "clear_bit(EVENT_RX_KILL, &dev->flags)", and vice ver
Hi,
On Mon, Aug 24, 2015 at 09:40:04PM +0530, Sanchayan Maity wrote:
> Hello,
>
> I am working on Freescale Vybrid which is a Cortex A5 based SoC,
> with a Chipidea based USB controller and a Sigmatel Phy or some-
> thing if my memory serves me right. We are currently in the process
> of implemen
Hello,
I am working on Freescale Vybrid which is a Cortex A5 based SoC,
with a Chipidea based USB controller and a Sigmatel Phy or some-
thing if my memory serves me right. We are currently in the process
of implementing suspend resume and fixing related issues. After
resume the USB PHY does not c
On Mon, Aug 24, 2015 at 11:43:21AM -0400, Alan Stern wrote:
> On Mon, 24 Aug 2015, Peter Chen wrote:
>
> > On Thu, Aug 20, 2015 at 05:03:46PM -0400, Alan Stern wrote:
> > > On Thu, 20 Aug 2015, Felipe Balbi wrote:
> > >
> > > > > > > - When using pattern = 1 as module parameters to compare the
>
On Sun, 23 Aug 2015, Roland Weber wrote:
> Hello Alan,
>
> bisecting turned out to be much simpler than I was afraid of.
> Here's the result:
>
> 638139eb95d2d241781330a321e88c8dafe46078 is the first bad commit
> commit 638139eb95d2d241781330a321e88c8dafe46078
> Author: Petr Mladek
> Date: Fr
On Mon, Aug 24, 2015 at 10:51:04AM -0400, Alan Stern wrote:
> On Mon, 24 Aug 2015, Peter Chen wrote:
>
> > Thanks, that's much clear.
> >
> > At udc driver:
> >
> > __set_halt(struct usb_ep *ep, int value, bool may_fail)
> > {
> > if (may_fail && ep queue is not empty) {
> > retu
On Mon, 24 Aug 2015, Peter Chen wrote:
> On Thu, Aug 20, 2015 at 05:03:46PM -0400, Alan Stern wrote:
> > On Thu, 20 Aug 2015, Felipe Balbi wrote:
> >
> > > > > > - When using pattern = 1 as module parameters to compare the data,
> > > > > > the
> > > > > > packet size must be same between host a
This is intended to add ZTE device PIDs on kernel.
Signed-off-by: Liu.Zhao
---
drivers/usb/serial/option.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 876423b..6b4a766 100644
--- a/drivers/usb/seria
On Mon, 24 Aug 2015, Peter Chen wrote:
> Thanks, that's much clear.
>
> At udc driver:
>
> __set_halt(struct usb_ep *ep, int value, bool may_fail)
> {
> if (may_fail && ep queue is not empty) {
> return false
> } else {
> do stall;
> return t
On Mon, 24 Aug 2015, Ramneek Mehresh wrote:
> > On Thu, 20 Aug 2015, Ramneek Mehresh wrote:
> >
> > > > > --- a/drivers/usb/host/ehci-fsl.h
> > > > > +++ b/drivers/usb/host/ehci-fsl.h
> > > > > @@ -63,4 +63,22 @@
> > > > > #define UTMI_PHY_EN (1<<9)
> > > > > #define ULPI_PHY_CLK_SE
Eugene Shatokhin writes:
> 19.08.2015 15:31, Bjørn Mork пишет:
>> Eugene Shatokhin writes:
>>
>>> The problem is not in the reordering but rather in the fact that
>>> "dev->flags = 0" is not necessarily atomic
>>> w.r.t. "clear_bit(EVENT_RX_KILL, &dev->flags)", and vice versa.
>>>
>>> So the fol
The OTG core will use struct otg_hcd_ops to
add/remove the HCD controller.
The main purpose of this interface is to avoid directly
calling usb_add/remove_hcd() 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
Reviewed-by:
Move the state_changed variable into struct otg_fsm
so that we can support multiple instances.
Signed-off-by: Roger Quadros
---
drivers/usb/common/usb-otg-fsm.c | 10 --
include/linux/usb/otg-fsm.h | 1 +
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/co
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.
Also get rid of MPC_LOC which doesn't seem to be used
by anyone.
[1] - warning fixed by this patch:
In file included from drivers/usb/dwc3/core.h:33,
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
Acked-by: Peter Chen
---
drivers/usb/common/usb-otg-fsm.c | 6 --
drivers/usb/phy/phy-fsl-usb.c| 2 ++
include/linux/usb/otg-fsm.h | 1 +
3 f
struct otg_fsm is the interface to the OTG state machine.
Document the input, output and internal state variables.
Definations are taken from Table 7-2 and Table 7-4 of
the USB OTG & EH Specification Rev.2.0
Re-arrange some of the members as per use case for more
clarity.
Signed-off-by: Roger Qu
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 Greg's usb-next tree.
Changelog:
The OTG core instantiates the OTG Finite State Machine
per OTG controller and manages starting/stopping the
host and gadget controllers based on the bus state.
It provides APIs for the following tasks
- Registering an OTG capable controller
- Registering Host and Gadget controllers to OTG core
-
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 Quadr
CONFIG_USB_OTG_FSM no longer exists and the OTG FSM
is available if CONFIG_USB_OTG is defined so move
to using CONFIG_USB_OTG.
Signed-off-by: Roger Quadros
---
Documentation/usb/chipidea.txt | 2 +-
drivers/usb/chipidea/Makefile | 2 +-
drivers/usb/chipidea/ci.h | 2 +-
drivers/usb/chipide
The OTG state machine needs a mechanism to start and
stop the gadget controller. Add usb_gadget_start()
and usb_gadget_stop().
Register with OTG core when gadget function driver
is available and unregister when function driver is unbound.
We need to unlock the usb_lock mutexbefore calling
usb_otg
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
--
The existing usb_add/remove_hcd() functionality
remains unchanged for non-OTG devices. For OTG
devices they only register the HCD with the OTG core.
Introduce usb_otg_add/remove_hcd() for use by OTG core.
These functions actually add/remove the HCD.
Signed-off-by: Roger Quadros
---
drivers/usb/
DRD mode is a reduced functionality OTG mode. In this mode
we don't support SRP, HNP and dynamic role-swap.
In DRD operation, the controller mode (Host or Peripheral)
is decided based on the ID pin status. Once a cable plug (Type-A
or Type-B) is attached the controller selects the state
and doesn'
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: Roger
On Mon, Aug 24, 2015 at 11:32:37AM +0200, Oliver Neukum wrote:
> On Mon, 2015-08-24 at 11:14 +0200, Yegor Yefremov wrote:
> > Applying your patch doesn't help, i.e. error messages disappear, but I
> > get following crash anyway (kernel 3.18.20):
>
> Johan, I think you need to limit the number of r
On Mon, Aug 24, 2015 at 11:14:13AM +0200, Yegor Yefremov wrote:
> On Mon, Aug 17, 2015 at 5:29 PM, Johan Hovold wrote:
> > This obviously does not solve the underlying issue, but could you try
> > the below patch nonetheless? We don't want these error messages for the
> > "valid" use case of remo
On Mon, Aug 24, 2015 at 09:51:33AM +0200, Bjørn Mork wrote:
> Johan Hovold writes:
> > On Wed, Aug 19, 2015 at 08:51:17AM -0700, Liu.Zhao wrote:
> >>
> >> #define BENQ_VENDOR_ID0x04a5
> >> #define BENQ_PRODUCT_H10 0x4068
> >> @@ -544,6 +548,14 @@ sta
19.08.2015 15:31, Bjørn Mork пишет:
Eugene Shatokhin writes:
The problem is not in the reordering but rather in the fact that
"dev->flags = 0" is not necessarily atomic
w.r.t. "clear_bit(EVENT_RX_KILL, &dev->flags)", and vice versa.
So the following might be possible, although unlikely:
CPU0
On Mon, Aug 24, 2015 at 2:29 PM, David Laight wrote:
> From: Vaishali Thakkar [mailto:vthakkar1...@gmail.com]
>> Sent: 22 August 2015 02:57
> ...
>> >> - .bcdADC = __constant_cpu_to_le16(0x0100),
>> >> - .wTotalLength = __constant_cpu_to_le16(UAC_DT_TOTAL_LENGTH),
>>
From: Mathias Nyman
> Sent: 24 August 2015 10:48
> On 23.08.2015 09:37, Vincent Pelletier wrote:
> >
> > I have one machine which fails to get a working USB bus on at least
> > every other boot. This machine having no PS2 ports, bus failure means
> > no keyboard, and a forced power cycle (sadly, th
On Thu, Aug 20, 2015 at 05:03:46PM -0400, Alan Stern wrote:
> On Thu, 20 Aug 2015, Felipe Balbi wrote:
>
> > > > > - When using pattern = 1 as module parameters to compare the data, the
> > > > > packet size must be same between host and device's.
> > > >
> > > > why ?
> > >
> > > The gadget sto
Hi
On 23.08.2015 09:37, Vincent Pelletier wrote:
Hello,
I have one machine which fails to get a working USB bus on at least
every other boot. This machine having no PS2 ports, bus failure means
no keyboard, and a forced power cycle (sadly, there is no accessible
reset button) to try again.
D
On Mon, 2015-08-24 at 11:14 +0200, Yegor Yefremov wrote:
> Applying your patch doesn't help, i.e. error messages disappear, but I
> get following crash anyway (kernel 3.18.20):
Johan, I think you need to limit the number of retries
and schedule a reset when the limit is hit.
Regards
Hi Johan,
On Mon, Aug 17, 2015 at 5:29 PM, Johan Hovold wrote:
> On Tue, Aug 11, 2015 at 12:31:47PM +0200, Yegor Yefremov wrote:
>> On Tue, Aug 11, 2015 at 11:58 AM, Bjørn Mork wrote:
>> > [replaced 'netdev' with 'linux-usb' as this concerns a USB serial driver
>> > only]
>> >
>> > Yegor Yefrem
From: Vaishali Thakkar [mailto:vthakkar1...@gmail.com]
> Sent: 22 August 2015 02:57
...
> >> - .bcdADC = __constant_cpu_to_le16(0x0100),
> >> - .wTotalLength = __constant_cpu_to_le16(UAC_DT_TOTAL_LENGTH),
> >> + .bcdADC = cpu_to_le16(0x0100),
> >> +
According to spec, there are functional and protocol stalls.
For functional stall, it is for bulk and interrupt endpoints,
below are cases for it:
- Host sends SET_FEATURE request for Set-Halt, the udc driver
needs to set stall, and return true unconditionally.
- The gadget driver may call usb_ep_
Johan Hovold writes:
> On Wed, Aug 19, 2015 at 08:51:17AM -0700, Liu.Zhao wrote:
>>
>> #define BENQ_VENDOR_ID 0x04a5
>> #define BENQ_PRODUCT_H100x4068
>> @@ -544,6 +548,14 @@ static const struct option_blacklist_info
>> zte_mc2716_z_blacklist =
On Wed, Aug 19, 2015 at 08:51:17AM -0700, Liu.Zhao wrote:
>
> This is intended to add ZTE device PIDs on kernel.
>
>
>
> Signed-off-by: Liu.Zhao
> ---
> drivers/usb/serial/option.c | 36
> 1 file changed, 28 insertions(+), 8 deletions(-)
>
> diff --git a/
On 21.08.2015 21:38, Marek Szyprowski wrote:
> Dear All,
>
> Since v3.19 s3c-hsotg (DWC2) USB controller stopped working on
> Exynos4412-based Trats2 platform. However on Odroid-U3 (which is also
> Exynos4412-based) it worked fine all the time. After long investigation
> it turned out that this wa
On Thu, Aug 20, 2015 at 06:06:22PM +0200, Sepp Käsbauer wrote:
> Hi Johan,
>
> if you want to take the following patch then the Mark-10 Force Gauge Series 5
> is supported by the cp210x driver. We have tested only with kernel > 4.1.5
> It works perfect.
>
> Thanks, Sepp Käsbauer
>
> see: http
79 matches
Mail list logo