On Thu, Sep 05, 2019 at 12:26:20AM +0200, beni.mah...@gmx.net wrote:
> From: Beni Mahler
>
> Both devices added here have a FTDI chip inside. The device from Echelon
> is called 'Network Interface' it is actually a LON network gateway.
>
> ID 0403:8348 Future Technology Devices International, L
On Mon, Sep 23, 2019 at 12:23:28PM +0200, Daniele Palmas wrote:
> This patch adds the following Telit FN980 compositions:
>
> 0x1050: tty, adb, rmnet, tty, tty, tty, tty
> 0x1051: tty, adb, mbim, tty, tty, tty, tty
> 0x1052: rndis, tty, adb, tty, tty, tty, tty
> 0x1053: tty, adb, ecm, tty, tty, tt
This reverts commits 3d109bdca981 ("ARM: dts: sunxi: Remove useless
phy-names from EHCI and OHCI"), 0a3df8bb6dad ("ARM: dts: sunxi: h3/h5:
Remove useless phy-names from EHCI and OHCI") and 3c7ab90aaa28 ("arm64:
dts: allwinner: Remove useless phy-names from EHCI and OHCI").
It turns out that while
While the original bindings that were superseeded by the YAML schemas
didn't mention that phy-names was needed, it turns out that phy-names is
required if phys is set according to phy/phy-bindings.txt.
Let's add back those properties.
Fixes: 14ec072a19ad ("dt-bindings: usb: Convert USB HCD generi
Hello Li Jun,
The patch 15b80f7c3a7f: "usb: chipidea: imx: enable vbus and id
wakeup only for OTG events" from Sep 9, 2019, leads to the following
static checker warning:
drivers/usb/chipidea/ci_hdrc_imx.c:438 ci_hdrc_imx_probe()
warn: 'data->usbmisc_data' can also be NULL
driver
Hi,
There has been a regression in the xhci driver since kernel version 4.20, on
some systems some usb devices won't work until the system gets rebooted.
The error message in dmesg is "WARN Set TR Deq Ptr cmd failed due to incorrect
slot or ep state", although for some reason there are some usb
All Tegra devices handled by tegra-udc use the same flags.
Consolidate all the entries under one roof.
Signed-off-by: Peter Geis
Acked-by: Thierry Reding
---
drivers/usb/chipidea/ci_hdrc_tegra.c | 22 +-
1 file changed, 5 insertions(+), 17 deletions(-)
diff --git a/drivers
On Tue, Oct 01, 2019 at 06:08:17AM -0700, Guenter Roeck wrote:
> On 10/1/19 2:48 AM, Heikki Krogerus wrote:
> > Copying everything from struct typec_capability to struct
> > typec_port during port registration.
> >
> What is the purpose of this patch ? To reduce the number of indirections at
> run
The device node name should reflect generic class of a device so rename
power domain nodes to "power-domain". No functional change.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4.dtsi| 14 +++---
arch/arm/boot/dts/exynos4210.dtsi | 2 +-
arch/arm/boot/dts/exynos44
Convert Generic Power Domain bindings to DT schema format using
json-schema. The consumer bindings are split to separate file.
Signed-off-by: Krzysztof Kozlowski
---
Changes since v1:
1. Select all nodes for consumers,
2. Remove from consumers duplicated properties with dt-schema,
3. Fix power
+ Li Jun
Hi Peter, Li,
On Mon, Sep 30, 2019 at 2:35 PM Igor Opaniuk wrote:
>
> Hi Peter,
>
> On Wed, Sep 25, 2019 at 3:44 AM Peter Chen wrote:
> >
> >
> > >
> > > Hi Fabio, Peter, Stefan,
> > >
> > > I've incidentally discovered your last year discussion in ML [1] (I hope
> > > it rings the
>
On Wed, Oct 02, 2019 at 07:06:52PM +0300, Heikki Krogerus wrote:
> On Tue, Oct 01, 2019 at 06:08:17AM -0700, Guenter Roeck wrote:
> > On 10/1/19 2:48 AM, Heikki Krogerus wrote:
> > > Copying everything from struct typec_capability to struct
> > > typec_port during port registration.
> > >
> > What
* Yegor Yefremov [191002 06:57]:
> On Wed, Oct 2, 2019 at 12:03 AM Tony Lindgren wrote:
> > The other way to fix this would be to just wake up cpp41 in
> > cppi41_dma_prep_slave_sg() and return NULL so that we can
> > have musb_ep_program() continue with PIO while cppi41 is
> > asleep.
> >
> > An
From: Aliasgar Surti
Status variable is initialized and returned without updating it's value.
Removed status variable and returned value directly.
Signed-off-by: Aliasgar Surti
---
drivers/usb/musb/musb_gadget.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/
On Wed, Oct 02, 2019 at 09:36:39AM -0700, Guenter Roeck wrote:
> port->cap->type used to be the role provided by the low level driver.
> That was static, and it was not possible to override it. It did not
> resemble the current port type, or a configured port type, it resembled
> port capabilities.
On Wed, Oct 02, 2019 at 07:06:55PM +0300, Heikki Krogerus wrote:
> This is a bit off topic, but that attribute file is really horrible.
> Right now there is no way to know the actual capability of the
> port in user space. If something changes a DRP port into sink or
> source, there is no way to kn
On 10/2/19 11:29 AM, Heikki Krogerus wrote:
On Wed, Oct 02, 2019 at 09:36:39AM -0700, Guenter Roeck wrote:
port->cap->type used to be the role provided by the low level driver.
That was static, and it was not possible to override it. It did not
resemble the current port type, or a configured por
On 10/2/19 12:16 PM, Heikki Krogerus wrote:
On Wed, Oct 02, 2019 at 07:06:55PM +0300, Heikki Krogerus wrote:
This is a bit off topic, but that attribute file is really horrible.
Right now there is no way to know the actual capability of the
port in user space. If something changes a DRP port int
18 matches
Mail list logo
