Switch from tty_port_register_device() to tty_port_register_device_serdev()
and from tty_unregister_device() to tty_port_unregister_device().
On removal of a serdev driver sometimes count mismatch warnings were seen:
ttyACM ttyACM0: tty_hangup: tty->count(1) != (#fd's(0) + #kopen's(0))
ttyACM
Ignore our device in cdc-acm probing and add a new driver for it,
dispatching to cdc-acm for the actual implementation.
WARNING: It is likely that this VID/PID is in use for unrelated devices.
Only the Product string hints what this really is in current v0.2.1.
Previous code v0.2.0 was using a Sem
The picoGW reference MCU firmware implements a USB CDC or UART interface
with a set of serial commands. It can be found on multiple mPCIe cards
as well as USB adapters.
https://github.com/Lora-net/picoGW_mcu
That MCU design superseded earlier attempts of using FTDI chips (MPSSE)
for controlling
Some drivers (e.g., serdev) may need to access private data not part of
the core sx130x_priv, which is inaccessible to other source files.
As the sx130x core expects to obtain the net_device from the dev's drvdata,
we can't reuse that in derived drivers and need a new field plus helpers.
Signed-of
Hello everyone,
Following up on a discussion in August 2018 [1] and my ELCE 2018 talk [2, 3],
I have been searching for an easy way to connect kernel network drivers to
a family of cards/adapters that expose a /dev/ttyACMx device today and
with the vendor's reference software would be accessed fro
Prepare for the picoGW by factoring code out into helpers using device
rather than spi_device.
While touching those lines, clean up the error output.
Split the probe function in two, to allow derived drivers to insert code
before the common probing code. This may need some more work.
Signed-off-
> > All this crossover code should be moved into the PHY driver.
>
> Fine, this can be done in a subsequent patch though, right ? I'd like to
> keep the changes small, so if something breaks, it could be bisected easily.
Hi Marek
The problem is, do you have a regression because of the changes yo
Hi Felipe,
Resending...
Since I am waiting on your suggestion, thought of giving remainder.
Thanks,
Anurag Kumar Vulisha
>-Original Message-
>From: Anurag Kumar Vulisha
>Sent: Wednesday, December 12, 2018 8:41 PM
>To: 'Alan Stern' ; Felipe Balbi
>Cc: Greg Kroah-Hartman ; Shuah Khan
>
On 1/4/19 2:24 PM, Andrew Lunn wrote:
>>> All this crossover code should be moved into the PHY driver.
>>
>> Fine, this can be done in a subsequent patch though, right ? I'd like to
>> keep the changes small, so if something breaks, it could be bisected easily.
>
> Hi Marek
Hi,
> The problem is,
[ Adding linux-usb ML to Cc, as it's a core USB issue ]
So the device seems incorrectly advertising as if it were supporting
UAC3 -- assuming the device is still not UAC3-capable.
IOW, it's a buggy firmware. We need some blacklisting, or revert the
commit for now, unless any real UAC3 device
> I wonder, if I use the phylib functions instead of the ad-hoc ones in
> the MAC driver, is there still a problem with synchronization ?
You would need to look deep into phylib. When does it reset the PHY?
Configure auto-neg, setup interrupts, etc? It looks like both are
going to do this, so i ex
On Thu, Jan 3, 2019 at 9:00 PM Min Guo wrote:
>
> On Thu, 2019-01-03 at 16:14 -0600, Rob Herring wrote:
> > On Thu, Dec 27, 2018 at 03:34:23PM +0800, min@mediatek.com wrote:
> > > From: Min Guo
> > >
> > > This adds support for MediaTek musb controller in
> > > host, peripheral and otg mode
Le 30/11/2018 à 17:15, Frédéric Parrenin a écrit :
Le 29/11/2018 à 15:10, mario.limoncie...@dell.com a écrit :
I tried with your patch but the Mac address pass-through still does not
work with the usbc adaptor, so it probably does not support it.
So I will buy a Dell one, it should work.
Th
This series provides basic USB support for MSM8998. Currently missing is
wiring up the Type-C detection logic so that the controller can correctly
switch between host and peripheral modes. Work to implement that is
ongoing, and expected to appear soon in followup patches.
Jeffrey Hugo (6):
clk
The usb30_master_clk supports a 60Mhz frequency, but that is missing from
the table of supported frequencies. Add it.
Fixes: b5f5f525c547 (clk: qcom: Add MSM8998 Global Clock Control (GCC) driver)
Signed-off-by: Jeffrey Hugo
---
drivers/clk/qcom/gcc-msm8998.c | 1 +
1 file changed, 1 insertion(
The gcc_usb3_phy_pipe_clk is generated by the phy, but is also used by
the phy during init. The clock needs to be enabled during the init
sequence, but may not be fully active until after the init sequence is
complete. This causes a catch-22 if the clock status is checked during
enable. As a res
MSM8998 contains one QUSB2 PHY which is very similar to the existing
sdm845 support.
Signed-off-by: Jeffrey Hugo
---
.../devicetree/bindings/phy/qcom-qusb2-phy.txt | 1 +
drivers/phy/qualcomm/phy-qcom-qusb2.c | 41 ++
2 files changed, 42 insertions(+)
diff
MSM8998 contains a single QMP v3 USB3 phy similar to the existing sdm845
support, however MSM8998 does not have display port (DP) support.
Signed-off-by: Jeffrey Hugo
---
.../devicetree/bindings/phy/qcom-qmp-phy.txt | 5 +
drivers/phy/qualcomm/phy-qcom-qmp.c| 142
Add a MSM8998 specific DT compatible so that we can properly bind to the
device and enable the USB controller.
Signed-off-by: Jeffrey Hugo
---
Documentation/devicetree/bindings/usb/qcom,dwc3.txt | 1 +
drivers/usb/dwc3/dwc3-qcom.c| 1 +
2 files changed, 2 insertions(+)
d
Add nodes for USB and related PHYs.
Signed-off-by: Jeffrey Hugo
---
arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi | 22
arch/arm64/boot/dts/qcom/msm8998.dtsi | 90 +++
2 files changed, 112 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi
> > [ Adding linux-usb ML to Cc, as it's a core USB issue ]
> >
> > So the device seems incorrectly advertising as if it were supporting
> > UAC3 -- assuming the device is still not UAC3-capable.
> >
> > IOW, it's a buggy firmware. We need some blacklisting, or revert the
> > commit for now, unles
On Fri, Jan 4, 2019 at 5:21 AM Andreas Färber wrote:
>
> Ignore our device in cdc-acm probing and add a new driver for it,
> dispatching to cdc-acm for the actual implementation.
>
> WARNING: It is likely that this VID/PID is in use for unrelated devices.
> Only the Product string hints what this
On 1/4/19 10:52 AM, Gopal, Saranya wrote:
[ Adding linux-usb ML to Cc, as it's a core USB issue ]
So the device seems incorrectly advertising as if it were supporting
UAC3 -- assuming the device is still not UAC3-capable.
IOW, it's a buggy firmware. We need some blacklisting, or revert the
c
From: Colin Ian King
There are two statements that are indented incorrectly and need
to be moved to a new line. Fix these.
Signed-off-by: Colin Ian King
---
drivers/usb/host/u132-hcd.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/u132-hcd.c b/driv
From: Colin Ian King
A return statement is indented one level too far, fix this by removing
a tab.
Signed-off-by: Colin Ian King
---
drivers/usb/musb/musb_host.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
inde
On 04.01.2019 16:57, Andrew Lunn wrote:
>> I wonder, if I use the phylib functions instead of the ad-hoc ones in
>> the MAC driver, is there still a problem with synchronization ?
>
> You would need to look deep into phylib. When does it reset the PHY?
> Configure auto-neg, setup interrupts, etc?
Hi Saranya.
On Sat, 5 Jan 2019 at 03:52, Gopal, Saranya wrote:
> And since I was not part of the initial mail thread, I might have missed some
> information.
> Could someone give me lsusb -v output for this USB audio device.
These outputs are with the UAC3 patch backed out:
dmesg:
[50384.8594
Fix spelling mistake: "lenght" -> "length"
Signed-off-by: Matteo Croce
---
drivers/usb/gadget/udc/aspeed-vhub/epn.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/udc/aspeed-vhub/epn.c
b/drivers/usb/gadget/udc/aspeed-vhub/epn.c
index 4a28e3fbeb0b..83340f4
Hi Rob,
Am 04.01.19 um 18:07 schrieb Rob Herring:
> On Fri, Jan 4, 2019 at 5:21 AM Andreas Färber wrote:
>>
>> Ignore our device in cdc-acm probing and add a new driver for it,
>> dispatching to cdc-acm for the actual implementation.
>>
>> WARNING: It is likely that this VID/PID is in use for unr
Am 04.01.19 um 12:21 schrieb Andreas Färber:
> diff --git a/drivers/net/lora/sx130x_picogw.c
> b/drivers/net/lora/sx130x_picogw.c
> new file mode 100644
> index ..577f9fb71d46
> --- /dev/null
> +++ b/drivers/net/lora/sx130x_picogw.c
[...]
> + serdev_device_set_baudrate(sdev, 115200
Am 04.01.19 um 12:21 schrieb Andreas Färber:
> Currently there's still some bugs to be investigated, with communication
> stalling on one device and another reading the radio versions wrong
> (07 / 1f instead of 21, also observed on spi once).
Reproducable 100% on SPI by setting REGCACHE_RBTREE in
31 matches
Mail list logo
