Hi,
On Thu, 2019-02-21 at 03:29 +, Peter Chen wrote:
>
> > On Mon, 2019-02-18 at 03:04 +, Peter Chen wrote:
> > > > According to the chipidea driver bindings, the USB PHY is specified via
> > > > the
> > "phys"
> > > > phandle node. However, this only takes effect for USB PHYs that use
Hi Greg,
On Wed, 20 Feb 2019, Greg Kroah-Hartman wrote:
On Wed, Feb 20, 2019 at 04:22:00PM +0100, Nikolaus Voss wrote:
v2: fix tps6598x_exec_cmd also
---
drivers/usb/typec/tps6598x.c | 26 --
1 file changed, 20 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/typ
> > If there is a generic PHY node under USB controller, and there is a
> > USB PHY at other sides, both ci->phy and ci->usb_phy are valid, I
> > original thought it is the problem you met.
>
> Right, this is not the problem we are having. The problem is that legacy USB
> PHYs
> are not grabbed
On Wed, Feb 20, 2019 at 09:54:12PM +0100, Jean-Philippe Menil wrote:
> On Wed, 20 Feb 2019, Greg KH wrote:
>
> > On Wed, Feb 20, 2019 at 07:50:52PM +0200, Mathias Nyman wrote:
> > > From: Jean-Philippe Menil
> > >
> > > Fix build warning when building drivers/usb/host/xhci-mem.o due to missing
>
Hi Guenther,
On Wed, 20 Feb 2019, Guenter Roeck wrote:
On 2/20/19 7:11 AM, Nikolaus Voss wrote:
From: Nikolaus Voss
Commit 1a2f474d328f handles block _reads_ separately with plain-I2C
adapters, but the problem described with regmap-i2c not handling
SMBus block transfers (i.e. read and writes)
On Thu, 2019-02-21 at 08:37 +, Peter Chen wrote:
>
> > > If there is a generic PHY node under USB controller, and there is a
> > > USB PHY at other sides, both ci->phy and ci->usb_phy are valid, I
> > > original thought it is the problem you met.
> >
> > Right, this is not the problem we are
On 20.2.2019 21.17, Greg KH wrote:
On Wed, Feb 20, 2019 at 07:50:53PM +0200, Mathias Nyman wrote:
From: Balaji Manoharan
This fix enables USB role feature on intel commercial nuc
platform which is based on Kabylake chipset.
Signed-off-by: Balaji Manoharan
Reviewed-by: Hans de Goede
Reviewed
On Wed, Feb 20, 2019 at 04:11:38PM +0100, Nikolaus Voss wrote:
> From: Nikolaus Voss
>
> Commit 1a2f474d328f handles block _reads_ separately with plain-I2C
> adapters, but the problem described with regmap-i2c not handling
> SMBus block transfers (i.e. read and writes) correctly also exists
> wi
On Mi, 2019-02-20 at 22:50 +, Jorge Augusto wrote:
> Dear developers,
> I have an ACER Aspire E1-522 but with this motherboard EG50-KB MB
> 12253-3M and the USB mouse stops working after resume and I need to
> unbind and bin OCHI-PCI to mouse starts working again
1. Is this a regression from a
> > Current code w/o your patch, it is possible both ci->phy and
> > ci->usb_phy are valid if the USB PHY is not at the device tree, but generic
> > PHY is
> at the device tree.
> > If you don't want to fix this issue with this patch, it is ok too. We could
> > fix it later.
>
> I'm not sure I
On Thu, 21 Feb 2019, Greg KH wrote:
> On Wed, Feb 20, 2019 at 09:54:12PM +0100, Jean-Philippe Menil wrote:
> > On Wed, 20 Feb 2019, Greg KH wrote:
> >
> > > On Wed, Feb 20, 2019 at 07:50:52PM +0200, Mathias Nyman wrote:
> > > > From: Jean-Philippe Menil
> > > >
> > > > Fix build warning when bu
On Thu, 21 Feb 2019, Heikki Krogerus wrote:
On Wed, Feb 20, 2019 at 04:11:38PM +0100, Nikolaus Voss wrote:
From: Nikolaus Voss
Commit 1a2f474d328f handles block _reads_ separately with plain-I2C
adapters, but the problem described with regmap-i2c not handling
SMBus block transfers (i.e. read a
Dear Oliver Neukum,
Thank you for your reply
I can't tell you if is a regression because is the first time I try to
use Linux in this Laptop
Yesterday I tried with kernel 4.10.0-38-generic and gave same error
dmesg:
[0.00] Linux version 4.15.0-45-generic
(buildd@lgw01-amd64-031) (gcc vers
On Thu, Feb 21, 2019 at 10:39:46AM +0100, Jean-Philippe Menil wrote:
> On Thu, 21 Feb 2019, Greg KH wrote:
>
> > On Wed, Feb 20, 2019 at 09:54:12PM +0100, Jean-Philippe Menil wrote:
> > > On Wed, 20 Feb 2019, Greg KH wrote:
> > >
> > > > On Wed, Feb 20, 2019 at 07:50:52PM +0200, Mathias Nyman wro
On Thu, Feb 21, 2019 at 10:56:18AM +0200, Mathias Nyman wrote:
> On 20.2.2019 21.17, Greg KH wrote:
> > On Wed, Feb 20, 2019 at 07:50:53PM +0200, Mathias Nyman wrote:
> > > From: Balaji Manoharan
> > >
> > > This fix enables USB role feature on intel commercial nuc
> > > platform which is based o
On Thu, Feb 21, 2019 at 09:37:33AM +0100, Nikolaus Voss wrote:
> Hi Greg,
>
> On Wed, 20 Feb 2019, Greg Kroah-Hartman wrote:
> > On Wed, Feb 20, 2019 at 04:22:00PM +0100, Nikolaus Voss wrote:
> > > > > v2: fix tps6598x_exec_cmd also
> > > > > ---
> > > > > drivers/usb/typec/tps6598x.c | 26 ++
On Thu, 21 Feb 2019, Greg KH wrote:
> On Thu, Feb 21, 2019 at 10:39:46AM +0100, Jean-Philippe Menil wrote:
> > On Thu, 21 Feb 2019, Greg KH wrote:
> >
> > > On Wed, Feb 20, 2019 at 09:54:12PM +0100, Jean-Philippe Menil wrote:
> > > > On Wed, 20 Feb 2019, Greg KH wrote:
> > > >
> > > > > On Wed,
On Thu, Feb 21, 2019 at 10:42:07AM +0100, Nikolaus Voss wrote:
> On Thu, 21 Feb 2019, Heikki Krogerus wrote:
> > On Wed, Feb 20, 2019 at 04:11:38PM +0100, Nikolaus Voss wrote:
> > > From: Nikolaus Voss
> > >
> > > Commit 1a2f474d328f handles block _reads_ separately with plain-I2C
> > > adapters,
dwc3_gadget_suspend() is called under dwc->lock spinlock. In such context
calling synchronize_irq() is not allowed. Move the problematic call out
of the protected block to fix the following kernel BUG during system
suspend:
BUG: sleeping function called from invalid context at kernel/irq/manage.c:
/0day-ci/linux/commits/Nikolaus-Voss/usb-typec-tps6598x-handle-block-writes-separately-with-plain-I2C-adapters/20190221-165456
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
usb-testing
config: i386-randconfig-a0-201907 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2
Hi,
On Thu, 2019-02-21 at 09:30 +, Peter Chen wrote:
>
> > > Current code w/o your patch, it is possible both ci->phy and
> > > ci->usb_phy are valid if the USB PHY is not at the device tree, but
> > > generic PHY is
> > at the device tree.
> > > If you don't want to fix this issue with thi
According to the chipidea driver bindings, the USB PHY is specified via
the "phys" phandle node. However, this only takes effect for USB PHYs
that use the common PHY framework. For legacy USB PHYs, a simple lookup
based on the USB PHY type is done instead.
This does not play out well when more tha
Refactor the code in charge of looking up the USB PHY when no platdata
is provided. Attempt to get a generic USB PHY first, then look for a
legacy USB PHY through device-tree and finally get any registered PHY
with the correct type.
This way, only a single USB PHY is obtained and the flow is easie
On Do, 2019-02-21 at 09:45 +, Jorge Augusto wrote:
> Dear Oliver Neukum,
> Thank you for your reply
>
> I can't tell you if is a regression because is the first time I try to
> use Linux in this Laptop
> Yesterday I tried with kernel 4.10.0-38-generic and gave same error
Hi,
either I am dens
On Thu, 21 Feb 2019, Oliver Neukum wrote:
> On Do, 2019-02-21 at 09:45 +, Jorge Augusto wrote:
> > Dear Oliver Neukum,
> > Thank you for your reply
> >
> > I can't tell you if is a regression because is the first time I try to
> > use Linux in this Laptop
> > Yesterday I tried with kernel 4.1
From: Thierry Reding
In order to be able to request an array of reset controls in acquired or
released mode, add the acquired flag to of_reset_control_array_get() and
pass the flag to subsequent calls of __of_reset_control_get().
Signed-off-by: Thierry Reding
---
drivers/reset/core.c
Dear Alan Stern,
thanks for the reply
Yes, that's the error I'm getting in the three kernel versions I've mentioned.
I've already tested without irqpoll setting as Oliver mentioned in
last email and I'm still getting the same error
However, if I unbind and bind ochi-pci the usb mouse starts work a
On Thu, 21 Feb 2019, Jorge Augusto wrote:
> Dear Alan Stern,
> thanks for the reply
>
> Yes, that's the error I'm getting in the three kernel versions I've mentioned.
> I've already tested without irqpoll setting as Oliver mentioned in
> last email and I'm still getting the same error
> However,
Hi Greg,
Here are my USB-serial updates for 5.1-rc1. I'll be sending a second request
for some device id's that I first had intended to forward for 5.0-rc as well.
Thanks,
Johan
The following changes since commit 49a57857aeea06ca831043acbb0fa5e0f50602fd:
Linux 5.0-rc3 (2019-01-21 13:14:44 +1
Dear Alan,
I've already tried it before and this failure only occurs with mouses
and keyboards
On Thu, Feb 21, 2019 at 3:59 PM Alan Stern wrote:
>
> On Thu, 21 Feb 2019, Jorge Augusto wrote:
>
> > Dear Alan Stern,
> > thanks for the reply
> >
> > Yes, that's the error I'm getting in the three ker
The following changes since commit f17b5f06cb92ef2250513a1e154c47b78df07d40:
Linux 5.0-rc4 (2019-01-27 15:18:05 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git
tags/usb-serial-5.1-rc1-2
for you to fetch changes up to 8d7fa
On Thu, Feb 21, 2019 at 05:13:52PM +0100, Johan Hovold wrote:
> Hi Greg,
>
> Here are my USB-serial updates for 5.1-rc1. I'll be sending a second request
> for some device id's that I first had intended to forward for 5.0-rc as well.
>
> Thanks,
> Johan
>
>
> The following changes since commit
On Thu, Feb 21, 2019 at 05:22:04PM +0100, Johan Hovold wrote:
> The following changes since commit f17b5f06cb92ef2250513a1e154c47b78df07d40:
>
> Linux 5.0-rc4 (2019-01-27 15:18:05 -0800)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb
Please don't top-post.
On Thu, 21 Feb 2019, Jorge Augusto wrote:
> Dear Alan,
> I've already tried it before and this failure only occurs with mouses
> and keyboards
Those are probably the only low- or full-speed devices you have. The
fact that the problem occurs with more than one type of dev
On 21-Feb-19 16:45, Alan Stern wrote:
Please don't top-post.
Sorry about that
Dear Alan,
I've already tried it before and this failure only occurs with mouses
and keyboards
Those are probably the only low- or full-speed devices you have. The
fact that the problem occurs with more than one ty
This series adds drivers and FPGA manager support required
for FT232H based ARRI FPGA configuration adapters.
Patch 1/3 adds FT232H interface driver (for ARRI USB PIDs)
implementing commonly used FTDI USB transfer operations and
ACBUS/MPSSE GPIO controllers. Depending on USB PIDs it creates
platfo
Add SPI bus controller driver for FTDI MPSSE mode. This driver
is supposed to be used together with the FT232H interface driver
for FPGA configuration in drivers/usb/misc/ft232h-intf.c which
adds an mpsse spi platform device describing USB SPI bus with
attached SPI slave devices.
Signed-off-by: An
Add FPGA manager driver for loading ARRI Altera FPGAs via fast
passive parallel (FPP) interface using FTDI FT232H chip.
Signed-off-by: Anatolij Gustschin
---
.../ABI/testing/sysfs-driver-ftdi-fifo-fpp| 7 +
drivers/fpga/Kconfig | 7 +
drivers/fpga/Makefile
Add USB interface driver for ARRI FPGA configuration devices based on
FTDI FT232H chip. Depending on USB PID the driver registers different
platform devices describing an FPGA configuration interface.
One FPGA configuration interface type is the usual SPI bus with
additional control and status GPI
On Wed, Feb 20, 2019 at 12:27 PM Mathias Nyman
wrote:
>
> I'm taking a different approach, USB3 ports in polling state should
> automatically move to connected/enabled. So instead of preventing
> suspend if a port is found in polling I'll let it try to finish link
> training for some time, and the
Hi Jiri,
Thanks for your comments. BND_MASK and BD_MASK are defined separately, and I
have tested RTL8153-BD and RTL8153-BND devices, both work as expected.
Thanks and Regards,
-David
> Jiri Slaby 於 2019年2月18日 下午10:22 寫道：
>
>> On 18. 02. 19, 15:00, David Chen wrote:
>> From: David Chen
>>
On Tue, 2019-02-19 at 11:20 +0800, Chen Yu wrote:
> Hi,
>
> On 2019/2/19 10:50, Chunfeng Yun wrote:
> >> + if (ret)
> >> + hisi_hikey_usb->typec_vbus_enable_val = 1;
> >> +
> >> + hisi_hikey_usb->typec_vbus = devm_gpiod_get(dev, "typec-vbus",
> >> + hisi_hikey_usb->type
42 matches
Mail list logo
