[PATCH RFC 4/5] usb: cdc-acm: Enable serdev support
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 ttyACM0: tty_port_close_start: tty->count = 1 port count = 0
Note: The serdev drivers appear to probe asynchronously as soon as they
are registered. Should the USB quirks in probe be moved before registration?
No noticeable difference for the devices at hand.
Cc: Rob Herring
Cc: Johan Hovold
Signed-off-by: Andreas Färber
---
drivers/usb/class/cdc-acm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index ed8c62b2d9d1..c225a586c524 100644
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -1460,7 +1460,7 @@ static int acm_probe(struct usb_interface *intf,
usb_set_intfdata(data_interface, acm);
usb_get_intf(control_interface);
- tty_dev = tty_port_register_device(&acm->port, acm_tty_driver, minor,
+ tty_dev = tty_port_register_device_serdev(&acm->port, acm_tty_driver,
minor,
&control_interface->dev);
if (IS_ERR(tty_dev)) {
rv = PTR_ERR(tty_dev);
@@ -1534,7 +1534,7 @@ static void acm_disconnect(struct usb_interface *intf)
acm_kill_urbs(acm);
cancel_work_sync(&acm->work);
- tty_unregister_device(acm_tty_driver, acm->minor);
+ tty_port_unregister_device(&acm->port, acm_tty_driver, acm->minor);
usb_free_urb(acm->ctrlurb);
for (i = 0; i < ACM_NW; i++)
--
2.16.4
[RFC lora-next 5/5] HACK: net: lora: sx130x: Add PicoCell gateway shim for cdc-acm
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 Semtech VID/PID, but no card shipping
with such firmware is known to me.
While this may seem unorthodox, no internals of the driver are accessed,
just the set of driver callbacks is duplicated as shim.
Use this shim construct to fake DT nodes for serdev on probe.
For testing purposes these nodes do not have a parent yet.
This results in two "Error -2 creating of_node link" warnings on probe.
Cc: Johan Hovold
Cc: Rob Herring
Signed-off-by: Andreas Färber
---
drivers/net/lora/Makefile | 2 +
drivers/net/lora/picogw.c | 337
drivers/usb/class/cdc-acm.c | 4 +
3 files changed, 343 insertions(+)
create mode 100644 drivers/net/lora/picogw.c
diff --git a/drivers/net/lora/Makefile b/drivers/net/lora/Makefile
index 5fef38abf5ed..bdcf7560dd65 100644
--- a/drivers/net/lora/Makefile
+++ b/drivers/net/lora/Makefile
@@ -27,6 +27,8 @@ lora-sx130x-y := sx130x.o
lora-sx130x-y += sx130x_radio.o
obj-$(CONFIG_LORA_SX130X) += lora-sx130x-picogw.o
lora-sx130x-picogw-y := sx130x_picogw.o
+obj-$(CONFIG_LORA_SX130X) += lora-picogw.o
+lora-picogw-y := picogw.o
obj-$(CONFIG_LORA_USI) += lora-usi.o
lora-usi-y := usi.o
diff --git a/drivers/net/lora/picogw.c b/drivers/net/lora/picogw.c
new file mode 100644
index ..aa5b83d21bb3
--- /dev/null
+++ b/drivers/net/lora/picogw.c
@@ -0,0 +1,337 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Semtech PicoCell gateway USB interface
+ *
+ * Copyright (c) 2018-2019 Andreas Färber
+ */
+
+#define pr_fmt(fmt) "picocell: " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define PICO_VID 0x0483
+#define PICO_PID 0x5740
+
+static struct usb_driver *picogw_get_acm_driver(struct usb_interface *iface)
+{
+ struct device_driver *drv;
+
+ drv = driver_find("cdc_acm", iface->dev.bus);
+ if (!drv)
+ return NULL;
+
+ return to_usb_driver(drv);
+}
+
+static void picogw_kobj_release(struct kobject *kobj)
+{
+ struct device_node *node = container_of(kobj, struct device_node, kobj);
+ struct property *prop;
+
+ prop = node->properties;
+ while (prop) {
+ struct property *next = prop->next;
+ kfree(prop);
+ prop = next;
+ }
+
+ kfree(node);
+}
+
+static struct kobj_type picogw_kobj_type = {
+ .release = picogw_kobj_release,
+};
+
+static u32 picogw_radio_a_reg = cpu_to_be32(0);
+static u32 picogw_radio_b_reg = cpu_to_be32(1);
+
+static int picogw_fake_of_nodes(struct device *dev)
+{
+ struct device_node *node = NULL;
+ struct device_node *child, *spi, *radio_a, *radio_b;
+ struct property *prop;
+
+ node = kzalloc(sizeof(*node), GFP_KERNEL);
+ if (!node)
+ return -ENOMEM;
+ node->name = "";
+ node->full_name = "usb0483,5740";
+ node->type = "";
+ kobject_init(&node->kobj, &picogw_kobj_type);
+ node->fwnode.ops = &of_fwnode_ops;
+
+ child = kzalloc(sizeof(*child), GFP_KERNEL);
+ if (!child) {
+ of_node_put(node);
+ return -ENOMEM;
+ }
+ child->name = "lora";
+ child->full_name = "lora";
+ child->type = "";
+ child->parent = node;
+ kobject_init(&child->kobj, &picogw_kobj_type);
+ child->fwnode.ops = &of_fwnode_ops;
+ node->child = child;
+
+ prop = kzalloc(sizeof(*prop), GFP_KERNEL);
+ if (!prop) {
+ of_node_put(child);
+ of_node_put(node);
+ return -ENOMEM;
+ }
+ prop->name = "compatible";
+ prop->value = "semtech,lora-picocell";
+ prop->length = 22;
+ child->properties = prop;
+
+ spi = kzalloc(sizeof(*spi), GFP_KERNEL);
+ if (!spi) {
+ of_node_put(child);
+ of_node_put(node);
+ return -ENOMEM;
+ }
+ spi->name = "radio-spi";
+ spi->full_name = "radio-spi";
+ spi->type = "";
+ spi->parent = child;
+ kobject_init(&spi->kobj, &picogw_kobj_type);
+ spi->fwnode.ops = &of_fwnode_ops;
+ child->child = spi;
+
+ radio_a = kzalloc(sizeof(*radio_a), GFP_KERNEL);
+ if (!radio_a) {
+ of_node_put(spi);
+ of_node_put(child);
+ of_node_put(node);
+ return -ENOMEM;
+ }
+ radio_a->name = "lora@0";
+ radio_a->full_name = "lora@0";
+ radio_a->type = "";
+ radio_a->parent = spi;
+ kobject_init(&radio_a->kobj, &picogw_kobj_type);
+ radio_a->fwnode.ops = &of_fwnode_ops;
+ spi->child = radio_a;
+
+ prop = kzalloc(sizeof(*prop), GFP_KERNEL);
[PATCH lora-next 3/5] net: lora: sx130x: Add PicoCell serdev driver
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 the SPI based chip directly from the host.
This commit adds a serdev driver implementing another regmap_bus to
abstract the register access and reuses our existing regmap driver on top.
Thereby we have an early proof of concept that we can drive both types
of modules/cards with a single driver core!
It assumes there is only one SX130x (with its radios) accessible, whereas
some new cards reportedly also have an SX127x on-board. So the DT/driver
design may need to be reconsidered once such a card or documentation
becomes available.
It also assumes SX1255/1258 are fully compatible with "semtech,sx1257".
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).
Signed-off-by: Andreas Färber
---
drivers/net/lora/Makefile| 2 +
drivers/net/lora/sx130x_picogw.c | 466 +++
2 files changed, 468 insertions(+)
create mode 100644 drivers/net/lora/sx130x_picogw.c
diff --git a/drivers/net/lora/Makefile b/drivers/net/lora/Makefile
index c6a0410f80ce..5fef38abf5ed 100644
--- a/drivers/net/lora/Makefile
+++ b/drivers/net/lora/Makefile
@@ -25,6 +25,8 @@ lora-sx127x-y := sx127x.o
obj-$(CONFIG_LORA_SX130X) += lora-sx130x.o
lora-sx130x-y := sx130x.o
lora-sx130x-y += sx130x_radio.o
+obj-$(CONFIG_LORA_SX130X) += lora-sx130x-picogw.o
+lora-sx130x-picogw-y := sx130x_picogw.o
obj-$(CONFIG_LORA_USI) += lora-usi.o
lora-usi-y := usi.o
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
@@ -0,0 +1,466 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Semtech SX1301/1308 PicoCell gateway serial MCU interface
+ *
+ * Copyright (c) 2018-2019 Andreas Färber
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct picogw_device {
+ struct serdev_device *serdev;
+
+ u8 rx_buf[1024];
+ int rx_len;
+
+ struct completion answer_comp;
+ struct completion answer_read_comp;
+};
+
+static inline struct picogw_device *picogw_get_drvdata(struct serdev_device
*sdev)
+{
+ return sx130x_get_drvdata(&sdev->dev);
+}
+
+static bool picogw_valid_cmd(char ch)
+{
+ switch (ch) {
+ case 'k': /* invalid command error */
+ case 'r':
+ case 'w':
+ case 'l':
+ return true;
+ default:
+ return false;
+ }
+}
+
+static int picogw_send_cmd(struct picogw_device *picodev, char cmd,
+ u8 addr, const void *data, u16 data_len)
+{
+ struct serdev_device *sdev = picodev->serdev;
+ u8 buf[4];
+ int i, ret;
+
+ buf[0] = cmd;
+ buf[1] = (data_len >> 8) & 0xff;
+ buf[2] = (data_len >> 0) & 0xff;
+ buf[3] = addr;
+
+ dev_dbg(&sdev->dev, "%s: %c %02x %02x %02x\n", __func__, buf[0],
+ (unsigned int)buf[1], (unsigned int)buf[2], (unsigned
int)buf[3]);
+ for (i = 0; i < data_len; i++) {
+ dev_dbg(&sdev->dev, "%s: data %02x\n", __func__, (unsigned
int)((const u8*)data)[i]);
+ }
+
+ ret = serdev_device_write_buf(sdev, buf, 4);
+ if (ret < 0)
+ return ret;
+ if (ret != 4)
+ return -EIO;
+
+ if (data_len) {
+ ret = serdev_device_write_buf(sdev, data, data_len);
+ if (ret < 0)
+ return ret;
+ if (ret != data_len)
+ return -EIO;
+ }
+
+ return 0;
+}
+
+static int picogw_recv_answer(struct picogw_device *picodev,
+ char *cmd, bool *ack, void *buf, int buf_len,
+ unsigned long timeout)
+{
+ int len;
+
+ timeout = wait_for_completion_timeout(&picodev->answer_comp, timeout);
+ if (!timeout)
+ return -ETIMEDOUT;
+
+ if (cmd)
+ *cmd = picodev->rx_buf[0];
+
+ if (ack)
+ *ack = (picodev->rx_buf[3] == 1);
+
+ len = min(picodev->rx_len - 4, buf_len);
+ if (buf)
+ memcpy(buf, picodev->rx_buf + 4, len);
+
+ reinit_completion(&picodev->answer_comp);
+ complete(&picodev->answer_read_comp);
+
+ return len;
+}
+
+static int picogw_reg_read(struct picogw_device *picodev, u8 addr, u8 *val,
unsigned long timeout)
+{
+ const u8 dummy = 0;
+ char cmd;
+ bool ack;
+ int ret;
+
+ ret = picogw_send_cmd(picodev, 'r', addr, &dummy, false ? 1 : 0);
+ if (ret)
+ return ret;
+
+ ret = picogw_recv_answer(picodev, &cmd,
[PATCH lora-next 2/5] net: lora: sx130x: Prepare storing driver-specific data
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-off-by: Andreas Färber
---
drivers/net/lora/sx130x.c | 19 +++
include/linux/lora/sx130x.h | 2 ++
2 files changed, 21 insertions(+)
diff --git a/drivers/net/lora/sx130x.c b/drivers/net/lora/sx130x.c
index 840052955874..978c921ca5ec 100644
--- a/drivers/net/lora/sx130x.c
+++ b/drivers/net/lora/sx130x.c
@@ -58,6 +58,7 @@ struct sx130x_priv {
struct regmap *regmap;
struct regmap_field
*regmap_fields[ARRAY_SIZE(sx130x_regmap_fields)];
struct mutexio_lock;
+ void*drvdata;
};
struct regmap *sx130x_get_regmap(struct device *dev)
@@ -68,6 +69,24 @@ struct regmap *sx130x_get_regmap(struct device *dev)
return priv->regmap;
}
+void sx130x_set_drvdata(struct device *dev, void *drvdata)
+{
+ struct net_device *netdev = dev_get_drvdata(dev);
+ struct sx130x_priv *priv = netdev_priv(netdev);
+
+ priv->drvdata = drvdata;
+}
+EXPORT_SYMBOL_GPL(sx130x_set_drvdata);
+
+void *sx130x_get_drvdata(struct device *dev)
+{
+ struct net_device *netdev = dev_get_drvdata(dev);
+ struct sx130x_priv *priv = netdev_priv(netdev);
+
+ return priv->drvdata;
+}
+EXPORT_SYMBOL_GPL(sx130x_get_drvdata);
+
void sx130x_io_lock(struct device *dev)
{
struct net_device *netdev = dev_get_drvdata(dev);
diff --git a/include/linux/lora/sx130x.h b/include/linux/lora/sx130x.h
index d6f027ef283f..85b088ec77b8 100644
--- a/include/linux/lora/sx130x.h
+++ b/include/linux/lora/sx130x.h
@@ -14,6 +14,8 @@
#include
extern const struct regmap_config sx130x_regmap_config;
+void sx130x_set_drvdata(struct device *dev, void *drvdata);
+void *sx130x_get_drvdata(struct device *dev);
int sx130x_early_probe(struct regmap *regmap, struct gpio_desc *rst);
int sx130x_probe(struct device *dev);
int sx130x_remove(struct device *dev);
--
2.16.4
[PATCH RFC lora-next 0/5] net: lora: sx130x: USB CDC Picocell Gateway serdev driver via fake DT nodes
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 from userspace. While a tty obviously works technically, it leaves us with per-vendor forks of userspace software without a real upstream community (rare code drops). It also doesn't allow code sharing with in-kernel protocol stacks or with the SPI and UART based drivers we've already been working on. One option suggested by Oliver was a line discipline - that would have the advantage that it could work with virtually any tty, but on the downside it would not work out-of-the-box and would require some userspace tool to manually switch the tty into the new mode. Scalability was another concern, as was duality of ldisc vs. serdev based implementations. This patchset rather explores the use of Device Tree nodes to load a serdev driver on top of the cdc-acm driver. By loading a modified cdc-acm module plus this quickly hacked-together usb driver, I could play with it on 4.20 on an arm based Turris Omnia router with n-fuse mPCIe card, for instance. I would hope that the shim approach taken here might also work for FTDI MPSSE based SPI, encountered by Frank. Not with serdev then, of course, but as pure USB interface/device driver piggy-backing on what exists. An unsolved problem is that Semtech in version v0.2.1 switched away from their own VID/PID to a generic STM32 VID/PID (due to Windows drivers...), with the only distinction in iProduct string that usb_device_id does not consider for probing. Since I'm reusing the cdc-acm driver, I can't have it fail in probe, as it would then fail when called from my driver, too. Various smaller issues are mentioned in the individual commit messages. This patchset is based on my linux-lora.git lora-next staging branch. Please consider taking the small usb patch to aid in further evaluating serdev on cdc-acm and in resolving the remaining issues. The others are for testing on our staging tree and for discussion. Have a lot of fun! Cheers, Andreas [1] https://marc.info/?l=linux-serial&m=153421371800416&w=2 [2] https://www.youtube.com/watch?v=Jjel65sZO9M [3] https://events.linuxfoundation.org/wp-content/uploads/2017/12/ELCE2018_LoRa_final_Andreas-Farber.pdf Cc: Johan Hovold Cc: Rob Herring Cc: Frank Kunz Cc: Oliver Neukum Cc: Andrew Lunn Cc: Sebastian Reichel Cc: devicet...@vger.kernel.org Cc: linux-lp...@lists.infradead.org Cc: linux-ser...@vger.kernel.org Cc: linux-usb@vger.kernel.org Cc: net...@vger.kernel.org Andreas Färber (5): net: lora: sx130x: Factor out SPI specific parts net: lora: sx130x: Prepare storing driver-specific data net: lora: sx130x: Add PicoCell serdev driver usb: cdc-acm: Enable serdev support HACK: net: lora: sx130x: Add PicoCell gateway shim for cdc-acm drivers/net/lora/Makefile| 4 + drivers/net/lora/picogw.c| 337 drivers/net/lora/sx130x.c| 158 - drivers/net/lora/sx130x_picogw.c | 466 +++ drivers/usb/class/cdc-acm.c | 8 +- include/linux/lora/sx130x.h | 9 + 6 files changed, 926 insertions(+), 56 deletions(-) create mode 100644 drivers/net/lora/picogw.c create mode 100644 drivers/net/lora/sx130x_picogw.c -- 2.16.4
[PATCH lora-next 1/5] net: lora: sx130x: Factor out SPI specific parts
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-by: Andreas Färber
---
drivers/net/lora/sx130x.c | 139 +++-
include/linux/lora/sx130x.h | 7 +++
2 files changed, 92 insertions(+), 54 deletions(-)
diff --git a/drivers/net/lora/sx130x.c b/drivers/net/lora/sx130x.c
index 9cae9cea195f..840052955874 100644
--- a/drivers/net/lora/sx130x.c
+++ b/drivers/net/lora/sx130x.c
@@ -133,7 +133,7 @@ static bool sx130x_readable_noinc_reg(struct device *dev,
unsigned int reg)
}
}
-static struct regmap_config sx130x_regmap_config = {
+const struct regmap_config sx130x_regmap_config = {
.reg_bits = 8,
.val_bits = 8,
@@ -151,6 +151,7 @@ static struct regmap_config sx130x_regmap_config = {
.num_ranges = ARRAY_SIZE(sx130x_regmap_ranges),
.max_register = SX1301_MAX_REGISTER,
};
+EXPORT_SYMBOL_GPL(sx130x_regmap_config);
static int sx130x_field_write(struct sx130x_priv *priv,
enum sx130x_fields field_id, u8 val)
@@ -537,110 +538,98 @@ static const struct net_device_ops sx130x_net_device_ops
= {
.ndo_start_xmit = sx130x_loradev_start_xmit,
};
-static int sx130x_probe(struct spi_device *spi)
+int sx130x_early_probe(struct regmap *regmap, struct gpio_desc *rst)
{
+ struct device *dev = regmap_get_device(regmap);
struct net_device *netdev;
struct sx130x_priv *priv;
- struct gpio_desc *rst;
int ret;
int i;
- unsigned int ver;
- unsigned int val;
-
- rst = devm_gpiod_get_optional(&spi->dev, "reset", GPIOD_OUT_LOW);
- if (IS_ERR(rst)) {
- if (PTR_ERR(rst) != -EPROBE_DEFER)
- dev_err(&spi->dev, "Failed to obtain reset GPIO\n");
- return PTR_ERR(rst);
- }
-
- gpiod_set_value_cansleep(rst, 1);
- msleep(100);
- gpiod_set_value_cansleep(rst, 0);
- msleep(100);
-
- spi->bits_per_word = 8;
- spi_setup(spi);
- netdev = devm_alloc_loradev(&spi->dev, sizeof(*priv));
+ netdev = devm_alloc_loradev(dev, sizeof(*priv));
if (!netdev)
return -ENOMEM;
netdev->netdev_ops = &sx130x_net_device_ops;
- SET_NETDEV_DEV(netdev, &spi->dev);
+ SET_NETDEV_DEV(netdev, dev);
priv = netdev_priv(netdev);
+ priv->regmap = regmap;
priv->rst_gpio = rst;
mutex_init(&priv->io_lock);
- spi_set_drvdata(spi, netdev);
- priv->dev = &spi->dev;
-
- priv->regmap = devm_regmap_init_spi(spi, &sx130x_regmap_config);
- if (IS_ERR(priv->regmap)) {
- ret = PTR_ERR(priv->regmap);
- dev_err(&spi->dev, "Regmap allocation failed: %d\n", ret);
- return ret;
- }
+ dev_set_drvdata(dev, netdev);
+ priv->dev = dev;
for (i = 0; i < ARRAY_SIZE(sx130x_regmap_fields); i++) {
const struct reg_field *reg_fields = sx130x_regmap_fields;
- priv->regmap_fields[i] = devm_regmap_field_alloc(&spi->dev,
+ priv->regmap_fields[i] = devm_regmap_field_alloc(dev,
priv->regmap,
reg_fields[i]);
if (IS_ERR(priv->regmap_fields[i])) {
ret = PTR_ERR(priv->regmap_fields[i]);
- dev_err(&spi->dev, "Cannot allocate regmap field:
%d\n", ret);
+ dev_err(dev, "Cannot allocate regmap field (%d)\n",
ret);
return ret;
}
}
+ return 0;
+}
+EXPORT_SYMBOL_GPL(sx130x_early_probe);
+
+int sx130x_probe(struct device *dev)
+{
+ struct net_device *netdev = dev_get_drvdata(dev);
+ struct sx130x_priv *priv = netdev_priv(netdev);
+ unsigned int ver;
+ unsigned int val;
+ int ret;
ret = regmap_read(priv->regmap, SX1301_VER, &ver);
if (ret) {
- dev_err(&spi->dev, "version read failed\n");
+ dev_err(dev, "version read failed (%d)\n", ret);
return ret;
}
if (ver != SX1301_CHIP_VERSION) {
- dev_err(&spi->dev, "unexpected version: %u\n", ver);
+ dev_err(dev, "unexpected version: %u\n", ver);
return -ENXIO;
}
ret = regmap_write(priv->regmap, SX1301_PAGE, 0);
if (ret) {
- dev_err(&spi->dev, "page/reset write failed\n");
+ dev_err(dev, "page/reset write failed (%d)\n", ret);
return ret;
}
ret = sx130x_field_write(priv, F_SOFT_RESET, 1);
if (ret) {
- dev_err(&spi->dev, "soft reset failed\n");
+ dev_err(dev, "soft reset f
Re: [PATCH 10/19] usbnet: smsc95xx: Replace smsc95xx_mdio_read() with phy_read()
> > 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 you made here, or because you have two things controlling the PHY, the MAC driver and the PHY driver, which are not coordinating? I don't know if you can do a piecemeal conversation like this. I don't remember anybody else doing anything like this before. What you can do piecemeal is add new functionality to the existing PHY driver. If you break the PHY driver we can then bisect it to find out which change broke it. Once the PHY driver has everything you need, then swap the MAC driver to use phylib. Thanks Andrew
RE: [PATCH v7 01/10] usb: gadget: udc: Add timer support for usb requests
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 >; Johan Hovold ; Jaejoong Kim >; Benjamin Herrenschmidt ; >Roger Quadros ; Manu Gautam ; >martin.peter...@oracle.com; Bart Van Assche ; Mike >Christie ; Matthew Wilcox ; Colin Ian >King ; linux-usb@vger.kernel.org; linux- >ker...@vger.kernel.org; v.anuragku...@gmail.com; Thinh Nguyen >; Tejas Joglekar ; Ajay >Yugalkishore Pandey >Subject: RE: [PATCH v7 01/10] usb: gadget: udc: Add timer support for usb >requests > > >Hi Felipe, > >>-Original Message- >>From: Alan Stern [mailto:st...@rowland.harvard.edu] >>Sent: Friday, December 07, 2018 10:40 PM >>To: Felipe Balbi >>Cc: Anurag Kumar Vulisha ; Greg Kroah-Hartman >>; Shuah Khan ; Johan Hovold >>; Jaejoong Kim ; Benjamin >>Herrenschmidt ; Roger Quadros ; >Manu >>Gautam ; martin.peter...@oracle.com; Bart Van >>Assche ; Mike Christie ; Matthew >>Wilcox ; Colin Ian King ; >>linux- >>u...@vger.kernel.org; linux-ker...@vger.kernel.org; v.anuragku...@gmail.com; >>Thinh Nguyen ; Tejas Joglekar >>; Ajay Yugalkishore Pandey >>Subject: RE: [PATCH v7 01/10] usb: gadget: udc: Add timer support for usb >>requests >> >>On Fri, 7 Dec 2018, Felipe Balbi wrote: >> >>> >>> hi, >>> >>> Anurag Kumar Vulisha writes: >>> >>Does the data book suggest a value for the timeout? >>> >> >>> > >>> > No, the databook doesn't mention about the timeout value >>> > >>> >>> >At this point, it seems that the generic approach will be messier than >>> >>> >having >>every >>> >>> >controller driver implement its own fix. At least, that's how it >>> >>> >appears to me. >>> >>> Why, if the UDC implementation will, anyway, be a timer? >> >>It's mostly a question of what happens when the timer expires. (After >>all, starting a timer is just as easy to do in a UDC driver as it is in >>the core.) When the timer expires, what can the core do? >> >>Don't say it can cancel the offending request and resubmit it. That >>leads to the sort of trouble we discussed earlier in this thread. In >>particular, we don't want the class driver's completion routine to be >>called when the cancel occurs. Furthermore, this leads to a race: >>Suppose the class driver decides to cancel the request at the same time >>as the core does a cancel and resubmit. Then the class driver's cancel >>could get lost and the request would remain on the UDC's queue. >> >>What you really want to do is issue the appropriate stop and restart >>commands to the hardware, while leaving the request logically active >>the entire time. The UDC core can't do this, but a UDC driver can. >> > >I agree with Alan's comment as it looks like there may be some corner cases >where the issue may occur with dequeue approach. Are you okay if the timeout >handler gets moved to the dwc3 driver (the timers still added into udc layer)? >Please let us know your suggestion on this > >Thanks, >Anurag Kumar Vulisha > >>> >>(Especially if dwc3 is the only driver affected.) >>> > >>> > As discussed above, the issue may happen with other gadgets too. As I got >>> > divide >>opinions >>> > on this implementation and both the implementations looks fine to me, I am >little >>confused >>> > on which should be implemented. >>> > >>> > @Felipe: Do you agree with Alan's implementation? Please let us know your >>suggestion >>> > on this. >>> >>> I still think a generic timer is a better solution since it has other uses. >> >>Putting a struct timer into struct usb_request is okay with me, but I >>wouldn't go any farther than that. >> >>> >>Since the purpose of the timeout is to detect a deadlock caused by a >>> >>hardware bug, I suggest a fixed and relatively short timeout value such >>> >>as one second. Cancelling and requeuing a few requests at 1-second >>> >>intervals shouldn't add very much overhead. >>> >>> I wouldn't call this a HW bug though. This is just how the UDC >>> behaves. There are N streams and host can move data in any stream at any >>> time. This means that host & gadget _can_ disagree on what stream to >>> start next. >> >>But the USB 3 spec says what should happen when the host and gadget >>disagree in this way, doesn't it? And it doesn't say that they should >>deadlock. :-) Or have I misread the spec? >> >>> One way to avoid this would be to never pre-start any streams and always >>> rely on XferNotReady, but that would mean greatly reduced throughput for >>> streams. >> >>It would be good if there was some way to actively detect the problem >>instead of passively waiting for a timer to expire. >> >>Alan Stern
Re: [PATCH 10/19] usbnet: smsc95xx: Replace smsc95xx_mdio_read() with phy_read()
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, do you have a regression because of the changes you > made here, or because you have two things controlling the PHY, the MAC > driver and the PHY driver, which are not coordinating? > > I don't know if you can do a piecemeal conversation like this. I don't > remember anybody else doing anything like this before. I'd prefer that. > What you can do piecemeal is add new functionality to the existing PHY > driver. If you break the PHY driver we can then bisect it to find out > which change broke it. Once the PHY driver has everything you need, > then swap the MAC driver to use phylib. 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 ? -- Best regards, Marek Vasut
Re: [alsa-devel] ALSA:usb audio Higher sample rates on usb audio no longer working.
[ 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 comes up to the market. IIRC an UAC3-capable device is required to expose a backwards-compatible configuration (either UAC1 or UAC2). Maybe an additional test can be done to harden the detection so that UAC3 is only chosen if indeed a second audio configuration is present as well. I also vaguely recall there was talk about adding information in the BOS descriptor, but I don't know if this was ever published. -Pierre
Re: [PATCH 10/19] usbnet: smsc95xx: Replace smsc95xx_mdio_read() with phy_read()
> 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 expect they are going to mess each other up. Andrew
Re: [PATCH 1/4] dt-bindings: usb: musb: Add support for MediaTek musb controller
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 [...] > > > + - interrupts : interrupt used by musb controller > > > + - interrupt-names : must be "mc" > > > > -names is pointless when there is only one. > The MUSB core driver has two interrupts, one is for MAC, another for DMA, > but on MTK platform, there is only a MAC interrupt, here following the binding > of MUSB core driver. You should probably be listing the same interrupt number twice if 2 interrupts are combined. > > > +Optional properties: > > > + - extcon : external connector for VBUS and IDPIN changes detection, > > > + needed when supports dual-role mode. > > > > Don't use extcon for new bindings. The usb-connector binding should be > > used instead. > This is used to detect the changes of the IDPIN and VBUS, the change > events are provided by other drivers, such as extcon-usb-gpio.c, and > then switch MUSB controller to host or device mode, but the > usb-connector can't detect these changes. To repeat, do not use extcon binding for new bindings. It is poorly designed as it reflects extcon driver needs, not a description of the hardware. If you have ID on GPIO, then that belongs in a usb-connector node because that GPIO goes to the connector. For Vbus, you should have a vbus-supply in the connector and use a gpio-regulator if it is GPIO controlled. > > > + - vbus-supply : reference to the VBUS regulator, needed when supports > > > + dual-role mode. > > > > The controller is powered from Vbus? Probably not. This belongs in the > > connector or maybe the phy (if the phy is powered from Vbus). > The Vbus is used to provide 5V voltage to the connected device when the > controller works as host mode. I know what Vbus is. Unless Vbus is providing power to the host controller, putting the Vbus supply in the controller node is not a accurate representation of the hardware. Rob
Re: Support Mac address pass through on Dell DS1000 dock
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. Thanks anyway. Frédéric OK, sounds good. For your information: I bought a Dell UsbC to RJ45 adaptor, and it works perfectly with Mac Address pass-through on linux. For your information: I re-installed windows 10 on this Dell Latitude 5285 laptop. So I tried again Mac pass-through with the UNI adaptor bought on Amazon. Network works, but with the adaptor Mac address, not the laptop Mac address, even when pass-through is enabled in the BIOS. So we have exactly the same behavior than on Linux. All the best, Frederic
[PATCH v1 0/6] MSM8998 basic USB support
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: qcom: Add missing freq for usb30_master_clk on 8998 clk: qcom: Skip halt checks on gcc_usb3_phy_pipe_clk for 8998 phy: qcom-qusb2: Add QUSB2 PHY support for msm8998 phy: qcom-qmp: Add QMP V3 USB3 PHY support for msm8998 usb: dwc3: qcom: Add support for MSM8998 arm64: dts: qcom: msm8998: Add USB-related nodes .../devicetree/bindings/phy/qcom-qmp-phy.txt | 5 + .../devicetree/bindings/phy/qcom-qusb2-phy.txt | 1 + .../devicetree/bindings/usb/qcom,dwc3.txt | 1 + arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi | 22 arch/arm64/boot/dts/qcom/msm8998.dtsi | 90 + drivers/clk/qcom/gcc-msm8998.c | 3 +- drivers/phy/qualcomm/phy-qcom-qmp.c| 142 + drivers/phy/qualcomm/phy-qcom-qmp.h| 4 + drivers/phy/qualcomm/phy-qcom-qusb2.c | 41 ++ drivers/usb/dwc3/dwc3-qcom.c | 1 + 10 files changed, 309 insertions(+), 1 deletion(-) -- Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
[PATCH v1 1/6] clk: qcom: Add missing freq for usb30_master_clk on 8998
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(+)
diff --git a/drivers/clk/qcom/gcc-msm8998.c b/drivers/clk/qcom/gcc-msm8998.c
index 1b77939..42de947 100644
--- a/drivers/clk/qcom/gcc-msm8998.c
+++ b/drivers/clk/qcom/gcc-msm8998.c
@@ -1112,6 +1112,7 @@ enum {
static const struct freq_tbl ftbl_usb30_master_clk_src[] = {
F(1920, P_XO, 1, 0, 0),
+ F(6000, P_GPLL0_OUT_MAIN, 10, 0, 0),
F(12000, P_GPLL0_OUT_MAIN, 5, 0, 0),
F(15000, P_GPLL0_OUT_MAIN, 4, 0, 0),
{ }
--
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
[PATCH v1 2/6] clk: qcom: Skip halt checks on gcc_usb3_phy_pipe_clk for 8998
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 result, skip the checks to avoid the troubling situation.
Signed-off-by: Jeffrey Hugo
---
drivers/clk/qcom/gcc-msm8998.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/qcom/gcc-msm8998.c b/drivers/clk/qcom/gcc-msm8998.c
index 42de947..1a1806a 100644
--- a/drivers/clk/qcom/gcc-msm8998.c
+++ b/drivers/clk/qcom/gcc-msm8998.c
@@ -2496,7 +2496,7 @@ enum {
static struct clk_branch gcc_usb3_phy_pipe_clk = {
.halt_reg = 0x50004,
- .halt_check = BRANCH_HALT,
+ .halt_check = BRANCH_HALT_SKIP,
.clkr = {
.enable_reg = 0x50004,
.enable_mask = BIT(0),
--
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
[PATCH v1 3/6] phy: qcom-qusb2: Add QUSB2 PHY support for msm8998
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 --git a/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
b/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
index 03025d9..3976847 100644
--- a/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
+++ b/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
@@ -6,6 +6,7 @@ QUSB2 controller supports LS/FS/HS usb connectivity on Qualcomm
chipsets.
Required properties:
- compatible: compatible list, contains
"qcom,msm8996-qusb2-phy" for 14nm PHY on msm8996,
+ "qcom,msm8998-qusb2-phy" for 10nm PHY on msm8996,
"qcom,sdm845-qusb2-phy" for 10nm PHY on sdm845.
- reg: offset and length of the PHY register set.
diff --git a/drivers/phy/qualcomm/phy-qcom-qusb2.c
b/drivers/phy/qualcomm/phy-qcom-qusb2.c
index 9177989f..e5e4f36 100644
--- a/drivers/phy/qualcomm/phy-qcom-qusb2.c
+++ b/drivers/phy/qualcomm/phy-qcom-qusb2.c
@@ -152,6 +152,32 @@ enum qusb2phy_reg_layout {
QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_PWR_CTRL, 0x00),
};
+static const unsigned int msm8998_regs_layout[] = {
+ [QUSB2PHY_PLL_CORE_INPUT_OVERRIDE] = 0xa8,
+ [QUSB2PHY_PLL_STATUS] = 0x1a0,
+ [QUSB2PHY_PORT_TUNE1] = 0x23c,
+ [QUSB2PHY_PORT_TUNE2] = 0x240,
+ [QUSB2PHY_PORT_TUNE3] = 0x244,
+ [QUSB2PHY_PORT_TUNE4] = 0x248,
+ [QUSB2PHY_PORT_TEST1] = 0x24c,
+ [QUSB2PHY_PORT_TEST2] = 0x250,
+ [QUSB2PHY_PORT_POWERDOWN] = 0x210,
+ [QUSB2PHY_INTR_CTRL] = 0x22c,
+};
+
+static const struct qusb2_phy_init_tbl msm8998_init_tbl[] = {
+ QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_ANALOG_CONTROLS_TWO, 0x13),
+ QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_CLOCK_INVERTERS, 0x7c),
+ QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_CMODE, 0x80),
+ QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_LOCK_DELAY, 0x0a),
+
+ QUSB2_PHY_INIT_CFG_L(QUSB2PHY_PORT_TUNE1, 0xa5),
+ QUSB2_PHY_INIT_CFG_L(QUSB2PHY_PORT_TUNE2, 0x09),
+
+ QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_DIGITAL_TIMERS_TWO, 0x19),
+};
+
+
static const unsigned int sdm845_regs_layout[] = {
[QUSB2PHY_PLL_CORE_INPUT_OVERRIDE] = 0xa8,
[QUSB2PHY_PLL_STATUS] = 0x1a0,
@@ -221,6 +247,18 @@ struct qusb2_phy_cfg {
.autoresume_en = BIT(3),
};
+static const struct qusb2_phy_cfg msm8998_phy_cfg = {
+ .tbl= msm8998_init_tbl,
+ .tbl_num= ARRAY_SIZE(msm8998_init_tbl),
+ .regs = msm8998_regs_layout,
+
+ .disable_ctrl = POWER_DOWN,
+ .mask_core_ready = CORE_READY_STATUS,
+ .has_pll_override = true,
+ .autoresume_en = BIT(0),
+ .update_tune1_with_efuse = true,
+};
+
static const struct qusb2_phy_cfg sdm845_phy_cfg = {
.tbl= sdm845_init_tbl,
.tbl_num= ARRAY_SIZE(sdm845_init_tbl),
@@ -734,6 +772,9 @@ static int qusb2_phy_exit(struct phy *phy)
.compatible = "qcom,msm8996-qusb2-phy",
.data = &msm8996_phy_cfg,
}, {
+ .compatible = "qcom,msm8998-qusb2-phy",
+ .data = &msm8998_phy_cfg,
+ }, {
.compatible = "qcom,sdm845-qusb2-phy",
.data = &sdm845_phy_cfg,
},
--
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
[PATCH v1 4/6] phy: qcom-qmp: Add QMP V3 USB3 PHY support for msm8998
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 +
drivers/phy/qualcomm/phy-qcom-qmp.h| 4 +
3 files changed, 151 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
index 41a1074..6061b6f 100644
--- a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
+++ b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
@@ -9,6 +9,7 @@ Required properties:
"qcom,ipq8074-qmp-pcie-phy" for PCIe phy on IPQ8074
"qcom,msm8996-qmp-pcie-phy" for 14nm PCIe phy on msm8996,
"qcom,msm8996-qmp-usb3-phy" for 14nm USB3 phy on msm8996,
+ "qcom,msm8998-qmp-usb3-phy" for USB3 QMP V3 phy on msm8998,
"qcom,sdm845-qmp-usb3-phy" for USB3 QMP V3 phy on sdm845,
"qcom,sdm845-qmp-usb3-uni-phy" for USB3 QMP V3 UNI phy on sdm845,
"qcom,sdm845-qmp-ufs-phy" for UFS QMP phy on sdm845.
@@ -42,6 +43,8 @@ Required properties:
"aux", "cfg_ahb", "ref".
For "qcom,msm8996-qmp-usb3-phy" must contain:
"aux", "cfg_ahb", "ref".
+ For "qcom,msm8998-qmp-usb3-phy" must contain:
+ "aux", "cfg_ahb", "ref".
For "qcom,sdm845-qmp-usb3-phy" must contain:
"aux", "cfg_ahb", "ref", "com_aux".
For "qcom,sdm845-qmp-usb3-uni-phy" must contain:
@@ -60,6 +63,8 @@ Required properties:
For "qcom,msm8996-qmp-pcie-phy" must contain:
"phy", "common", "cfg".
For "qcom,msm8996-qmp-usb3-phy" must contain
+"phy", "common".
+ For "qcom,msm8998-qmp-usb3-phy" must contain
"phy", "common".
For "qcom,sdm845-qmp-usb3-phy" must contain:
"phy", "common".
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index b400681..c0111a6 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -687,6 +687,116 @@ enum qphy_reg_layout {
QMP_PHY_INIT_CFG(QPHY_V3_PCS_MULTI_LANE_CTRL1, 0x02),
};
+static const struct qmp_phy_init_tbl msm8998_usb3_serdes_tbl[] = {
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_CLK_SELECT, 0x30),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_BIAS_EN_CLKBUFLR_EN, 0x04),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_SYSCLK_EN_SEL, 0x14),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_SYS_CLK_CTRL, 0x06),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_RESETSM_CNTRL2, 0x08),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_CMN_CONFIG, 0x06),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_SVS_MODE_CLK_SEL, 0x01),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_HSCLK_SEL, 0x80),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_DEC_START_MODE0, 0x82),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_DIV_FRAC_START1_MODE0, 0xab),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_DIV_FRAC_START2_MODE0, 0xea),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_DIV_FRAC_START3_MODE0, 0x02),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_CP_CTRL_MODE0, 0x06),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_PLL_RCTRL_MODE0, 0x16),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_PLL_CCTRL_MODE0, 0x36),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_INTEGLOOP_GAIN1_MODE0, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_INTEGLOOP_GAIN0_MODE0, 0x3f),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE2_MODE0, 0x01),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE1_MODE0, 0xc9),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_CORECLK_DIV_MODE0, 0x0a),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP3_MODE0, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP2_MODE0, 0x34),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP1_MODE0, 0x15),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP_EN, 0x04),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_CORE_CLK_EN, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP_CFG, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE_MAP, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_BG_TIMER, 0x0a),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_PLL_IVCO, 0x07),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_INTEGLOOP_INITVAL, 0x80),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_CMN_MODE, 0x01),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_SSC_EN_CENTER, 0x01),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_SSC_PER1, 0x31),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_SSC_PER2, 0x01),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_SSC_ADJ_PER1, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_SSC_ADJ_PER2, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_SSC_STEP_SIZE1, 0x85),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_SSC_STEP_SIZE2, 0x07),
+};
+
+static const struct qmp_phy_init_tbl msm89
[PATCH v1 5/6] usb: dwc3: qcom: Add support for MSM8998
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(+)
diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.txt
b/Documentation/devicetree/bindings/usb/qcom,dwc3.txt
index 95afdcf..cb695aa 100644
--- a/Documentation/devicetree/bindings/usb/qcom,dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.txt
@@ -4,6 +4,7 @@ Required properties:
- compatible: Compatible list, contains
"qcom,dwc3"
"qcom,msm8996-dwc3" for msm8996 SOC.
+ "qcom,msm8998-dwc3" for msm8998 SOC.
"qcom,sdm845-dwc3" for sdm845 SOC.
- reg: Offset and length of register set for QSCRATCH wrapper
- power-domains: specifies a phandle to PM domain provider node
diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
index a6d0203..184df4d 100644
--- a/drivers/usb/dwc3/dwc3-qcom.c
+++ b/drivers/usb/dwc3/dwc3-qcom.c
@@ -595,6 +595,7 @@ static int __maybe_unused dwc3_qcom_runtime_resume(struct
device *dev)
static const struct of_device_id dwc3_qcom_of_match[] = {
{ .compatible = "qcom,dwc3" },
{ .compatible = "qcom,msm8996-dwc3" },
+ { .compatible = "qcom,msm8998-dwc3" },
{ .compatible = "qcom,sdm845-dwc3" },
{ }
};
--
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
[PATCH v1 6/6] arm64: dts: qcom: msm8998: Add USB-related nodes
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
b/arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi
index 50e9033..dc703fc 100644
--- a/arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi
@@ -257,3 +257,25 @@
pinctrl-0 = <&sdc2_clk_on &sdc2_cmd_on &sdc2_data_on &sdc2_cd_on>;
pinctrl-1 = <&sdc2_clk_off &sdc2_cmd_off &sdc2_data_off &sdc2_cd_off>;
};
+
+&usb1 {
+ status = "okay";
+};
+
+&usb1_dwc3 {
+ dr_mode = "host"; /* Force to host until we have Type-C hooked up */
+};
+
+&usb1_hsphy {
+ status = "okay";
+
+ vdda-pll-supply = <&vreg_l12a_1p8>;
+ vdda-phy-dpdm-supply = <&vreg_l24a_3p075>;
+};
+
+&usb1_qmpphy {
+ status = "okay";
+
+ vdda-phy-supply = <&vreg_l1a_0p875>;
+ vdda-pll-supply = <&vreg_l2a_1p2>;
+};
diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi
b/arch/arm64/boot/dts/qcom/msm8998.dtsi
index 8d41b69..7c31c97 100644
--- a/arch/arm64/boot/dts/qcom/msm8998.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi
@@ -540,6 +540,11 @@
reg = <0x78 0x621c>;
#address-cells = <1>;
#size-cells = <1>;
+
+ qusb2_hstx_trim: hstx-trim@423a {
+ reg = <0x423a 0x1>;
+ bits = <0 4>;
+ };
};
gcc: clock-controller@10 {
@@ -607,6 +612,91 @@
#mbox-cells = <1>;
};
+ usb1: usb@a8f8800 {
+ compatible = "qcom,msm8998-dwc3", "qcom,dwc3";
+ reg = <0xa8f8800 0x400>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ clocks = <&gcc GCC_CFG_NOC_USB3_AXI_CLK>,
+<&gcc GCC_USB30_MASTER_CLK>,
+<&gcc GCC_AGGRE1_USB3_AXI_CLK>,
+<&gcc GCC_USB30_MOCK_UTMI_CLK>,
+<&gcc GCC_USB30_SLEEP_CLK>;
+ clock-names = "cfg_noc", "core", "iface", "mock_utmi",
+ "sleep";
+
+ assigned-clocks = <&gcc GCC_USB30_MOCK_UTMI_CLK>,
+ <&gcc GCC_USB30_MASTER_CLK>;
+ assigned-clock-rates = <1920>, <12000>;
+
+ interrupts = ,
+;
+ interrupt-names = "hs_phy_irq", "ss_phy_irq";
+
+ power-domains = <&gcc USB_30_GDSC>;
+
+ resets = <&gcc GCC_USB_30_BCR>;
+
+ usb1_dwc3: dwc3@a80 {
+ compatible = "snps,dwc3";
+ reg = <0xa80 0xcd00>;
+ interrupts = ;
+ snps,dis_u2_susphy_quirk;
+ snps,dis_enblslpm_quirk;
+ phys = <&usb1_hsphy>, <&usb1_ssphy>;
+ phy-names = "usb2-phy", "usb3-phy";
+ snps,has-lpm-erratum;
+ snps,hird-threshold = /bits/ 8 <0x10>;
+ };
+ };
+
+ usb1_qmpphy: phy@c01 {
+ compatible = "qcom,msm8998-qmp-usb3-phy";
+ reg = <0xc01 0x18c>;
+ status = "disabled";
+ #clock-cells = <1>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ clocks = <&gcc GCC_USB3_PHY_AUX_CLK>,
+<&gcc GCC_USB_PHY_CFG_AHB2PHY_CLK>,
+<&gcc GCC_USB3_CLKREF_CLK>;
+ clock-names = "aux", "cfg_ahb", "ref";
+
+ resets = <&gcc GCC_USB3_PHY_BCR>,
+<&gcc GCC_USB3PHY_PHY_BCR>;
+ reset-names = "phy", "common";
+
+ usb1_ssphy: lane@c010200 {
+ reg = <0xc010200 0x128>,
+ <0xc010400 0x200>,
+ <0xc010c00 0x20c>;
+ #phy-cells = <0>;
+ clocks = <&gcc GCC_USB3_PHY_PIPE_CLK>;
+ clock-names = "pipe0";
+ clock-output-names = "usb3_phy_pipe_clk_src";
+ };
+ };
RE: [alsa-devel] ALSA:usb audio Higher sample rates on usb audio no longer working.
> > [ 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 comes up to the market. > > IIRC an UAC3-capable device is required to expose a backwards-compatible > configuration (either UAC1 or UAC2). Maybe an additional test can be > done to harden the detection so that UAC3 is only chosen if indeed a > second audio configuration is present as well. > > I also vaguely recall there was talk about adding information in the BOS > descriptor, but I don't know if this was ever published. > > -Pierre The current detection logic is that UAC3 configuration is chosen only when a device has a configuration with audio interface supporting UAC3 protocol. Additionally, it already makes sure that UAC3 is selected only when there is more than one configuration. Otherwise, the first configuration is chosen by default. So, the patch does not affect existing UAC1 and UAC2 devices. As Iwai said, this issue seems to be because of a buggy firmware which wrongly advertises UAC3-capability. Could we add some quirk to select another configuration for this particular device? I see that there is a similar in quirk in sound/usb/quirks.c (snd_usb_fasttrackpro_boot_quirk) . Could something like that be done for this particular device? 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. Thanks, Saranya
Re: [RFC lora-next 5/5] HACK: net: lora: sx130x: Add PicoCell gateway shim for cdc-acm
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 really is in current v0.2.1. > Previous code v0.2.0 was using a Semtech VID/PID, but no card shipping > with such firmware is known to me. > > While this may seem unorthodox, no internals of the driver are accessed, > just the set of driver callbacks is duplicated as shim. > > Use this shim construct to fake DT nodes for serdev on probe. > For testing purposes these nodes do not have a parent yet. > This results in two "Error -2 creating of_node link" warnings on probe. It looks like the DT is pretty static. Rather than creating the nodes at run-time, can't you create a dts file and build that into your module. Rob
Re: [alsa-devel] ALSA:usb audio Higher sample rates on usb audio no longer working.
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 commit for now, unless any real UAC3 device comes up to the market. IIRC an UAC3-capable device is required to expose a backwards-compatible configuration (either UAC1 or UAC2). Maybe an additional test can be done to harden the detection so that UAC3 is only chosen if indeed a second audio configuration is present as well. I also vaguely recall there was talk about adding information in the BOS descriptor, but I don't know if this was ever published. -Pierre The current detection logic is that UAC3 configuration is chosen only when a device has a configuration with audio interface supporting UAC3 protocol. Additionally, it already makes sure that UAC3 is selected only when there is more than one configuration. What I meant if that the other configurations are not checked for UAC1 or UAC2 capabilities, you only check that there is more than one configuration
[PATCH] usb: host: u132-hcd: fix a couple of indentation issues
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/drivers/usb/host/u132-hcd.c
index 5b8a3d9530c4..934584f0a20a 100644
--- a/drivers/usb/host/u132-hcd.c
+++ b/drivers/usb/host/u132-hcd.c
@@ -2477,7 +2477,8 @@ static int u132_endp_urb_dequeue(struct u132 *u132,
struct u132_endp *endp,
spin_unlock_irqrestore(&endp->queue_lock.slock,
irqs);
kfree(urbq);
- } urb->error_count = 0;
+ }
+ urb->error_count = 0;
usb_hcd_giveback_urb(hcd, urb, status);
return 0;
} else if (list_empty(&endp->urb_more)) {
@@ -2982,7 +2983,8 @@ static int u132_remove(struct platform_device *pdev)
while (rings-- > 0) {
struct u132_ring *ring = &u132->ring[rings];
u132_ring_cancel_work(u132, ring);
- } while (endps-- > 0) {
+ }
+ while (endps-- > 0) {
struct u132_endp *endp = u132->endp[endps];
if (endp)
u132_endp_cancel_work(u132, endp);
--
2.19.1
[PATCH] USB: musb: fix indentation issue on a return statement
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 index b59ce9ad14ce..0b1eb15b6b08 100644 --- a/drivers/usb/musb/musb_host.c +++ b/drivers/usb/musb/musb_host.c @@ -1283,7 +1283,7 @@ void musb_host_tx(struct musb *musb, u8 epnum) MUSB_TXCSR_H_WZC_BITS | MUSB_TXCSR_TXPKTRDY); } - return; + return; } done: -- 2.19.1
Re: [PATCH 10/19] usbnet: smsc95xx: Replace smsc95xx_mdio_read() with phy_read()
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? It looks like both are
> going to do this, so i expect they are going to mess each other up.
>
Marek, I recently went through this exercise when switching r8169
driver to phylib. As Andrew explained:
First add needed functionality to the respective PHY driver(s),
then you can switch the network driver.
You can look at f1e911d5d0df ("r8169: add basic phylib support")
plus related changes, and to what was added to the Realtek PHY
driver module.
Re: [alsa-devel] ALSA:usb audio Higher sample rates on usb audio no longer working.
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.859492] usb 2-1.8.4: new high-speed USB device number 26 using ehci-pci [50384.974496] usb 2-1.8.4: New USB device found, idVendor=19fb, idProduct=2040, bcdDevice= 2.00 [50384.974500] usb 2-1.8.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [50384.974501] usb 2-1.8.4: Product: Anti-Mode X4 [50384.974503] usb 2-1.8.4: Manufacturer: DSPeaker lsusb -v: Bus 002 Device 026: ID 19fb:2040 Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 ? bDeviceProtocol 1 Interface Association bMaxPacketSize064 idVendor 0x19fb idProduct 0x2040 bcdDevice2.00 iManufacturer 1 DSPeaker iProduct2 Anti-Mode X4 iSerial 0 bNumConfigurations 2 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 254 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 100mA Interface Association: bLength 8 bDescriptorType11 bFirstInterface 0 bInterfaceCount 2 bFunctionClass 1 Audio bFunctionSubClass 0 bFunctionProtocol 32 iFunction 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 1 Audio bInterfaceSubClass 1 Control Device bInterfaceProtocol 32 iInterface 0 AudioControl Interface Descriptor: bLength 9 bDescriptorType36 bDescriptorSubtype 1 (HEADER) bcdADC 2.00 bCategory 10 wTotalLength 60 bmControl0x00 AudioControl Interface Descriptor: bLength 8 bDescriptorType36 bDescriptorSubtype 10 (CLOCK_SOURCE) bClockID 41 bmAttributes 0x03 Internal programmable Clock bmControls 0x07 Clock Frequency Control (read/write) Clock Validity Control (read-only) bAssocTerminal 0 iClockSource0 AudioControl Interface Descriptor: bLength 8 bDescriptorType36 bDescriptorSubtype 11 (CLOCK_SELECTOR) bUnitID40 bNrInPins 1 baCSourceID( 0)41 bmControls 0x00 iClockSelector 0 AudioControl Interface Descriptor: bLength17 bDescriptorType36 bDescriptorSubtype 2 (INPUT_TERMINAL) bTerminalID 1 wTerminalType 0x0101 USB Streaming bAssocTerminal 0 bCSourceID 40 bNrChannels 2 bmChannelConfig 0x bmControls0x iChannelNames 4 Analog 1 iTerminal 0 AudioControl Interface Descriptor: bLength18 bDescriptorType36 bDescriptorSubtype 6 (FEATURE_UNIT) bUnitID 3 bSourceID 1 bmaControls( 0) 0x000f Mute Control (read/write) Volume Control (read/write) bmaControls( 1) 0x bmaControls( 2) 0x iFeature0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 1 Audio bInterfaceSubClass 2 Streaming bInterfaceProtocol 32 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 1 bNumEndpoints 2 bInterfaceClass 1 Audio bInterfaceSubClass 2 Streaming bInterfaceProtocol 32 iInterface 0 AudioStreaming Interface Descriptor: bLength16 bDescriptorType36 bDescriptorSubtype 1 (AS_GENERAL) bTerminalLink 1 bmControls 0x00 bFormatType
[PATCH] usb/gadget: fix typo
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..83340f4fdc6e 100644 --- a/drivers/usb/gadget/udc/aspeed-vhub/epn.c +++ b/drivers/usb/gadget/udc/aspeed-vhub/epn.c @@ -120,7 +120,7 @@ static void ast_vhub_epn_handle_ack(struct ast_vhub_ep *ep) /* No current DMA ongoing */ req->active = false; - /* Grab lenght out of HW */ + /* Grab length out of HW */ len = VHUB_EP_DMA_TX_SIZE(stat); /* If not using DMA, copy data out if needed */ -- 2.20.1
Re: [RFC lora-next 5/5] HACK: net: lora: sx130x: Add PicoCell gateway shim for cdc-acm
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 unrelated devices. >> Only the Product string hints what this really is in current v0.2.1. >> Previous code v0.2.0 was using a Semtech VID/PID, but no card shipping >> with such firmware is known to me. >> >> While this may seem unorthodox, no internals of the driver are accessed, >> just the set of driver callbacks is duplicated as shim. >> >> Use this shim construct to fake DT nodes for serdev on probe. >> For testing purposes these nodes do not have a parent yet. >> This results in two "Error -2 creating of_node link" warnings on probe. > > It looks like the DT is pretty static. Rather than creating the nodes > at run-time, can't you create a dts file and build that into your > module. Heh, if that were the only issue with this patch... ;) I had read about that possibility here [1], but it just appeared to give me a binary blob with no handy documentation on how to parse the __dtb_XXX_begin..__dtb_XXX_end blob afterwards for assignment to interface->dev.of_node. Two nodes and one compatible property were enough to get me started, so that was quickest, given lack of knowledge. I intentionally left it static to keep error handling and cleanup manageable for now... Otherwise I'd need to kstrdup()/kzalloc() all properties so that I can consistently kfree() them again on release. Note that this was just a PoC, so there are properties missing here: At least currently Ben's patch [2] (wrongly?) relies on the optional clock-output-names property if #clock-cells property is specified - which I did not in this patch. (Thus it'll disable clk_out, which would break opening the netdev if we wouldn't run into other errors first.) Any comments on how to best deal with clk names on the driver side would be appreciated, so that we can just leave the property away here and get a sane default name. Otherwise we'd need to generate a unique name here. If #clock-cells were present, the driver would also rely on obtaining a parent clock, which may be easiest for me to fix in the driver; but assuming we need it, we'd need a clocks property pointing to phandles. Wouldn't phandles need to be unique globally in the kernel for lookup? phandles from a separate .dtb fragment wouldn't seem to tick that box. (For reference there's also a clk locking issue under discussion at [3], as well as multiple unresolved Kbuild reports about clk_hw not being applicable on sparc64 allyesconfigs and m68k allmodconfig that I'm unsure how to best resolve while keeping the driver broadly usable. Not using clk would solve above DT worries but would leave us with ugly driver dependencies across spi and a custom sx130x_radio bus.) Kconfig may also be a topic to consider for this USB driver - my x86_64 host for instance doesn't have CONFIG_OF, so it might work to manually allocate such nodes, whereas using API or &of_fwnode_ops (needed?) may be a problem - although without CONFIG_OF the serdev code probably is unable to enumerate the nodes in the first place? And I assume on ACPI platforms hot-pluggable USB devices shouldn't need a user-overridden ACPI table either - have you thought about some serdev-specific lookup as fallback when OF and ACPI come up empty? Your drivers/tty/serdev/core.c:serdev_controller_add() has access to ctrl->dev->parent, so it could maintain a list of callbacks that drivers (e.g., cdc-acm) could register callbacks with and cast the device here to usb_interface; my module here would then only need to register such a callback against cdc-acm in its module init to allow cdc-acm to provide it with the usb_interface, where it could then check for the iProduct to determine whether that device should be serdev-controlled or not - say by returning 0 to bind, negative error to ignore - and loading/creating an internal of_node or whatever necessary. Just a rough idea for now... Even easier, serdev_device_driver could just get an optional callback! Then my driver in 3/5 could just determine itself which device it wants to bind against and still use the module_serdev_device_driver() macro. (serdev is built-in, so not as easy to tweak on random boards here...) Any comments on serdev in 4/5? I wonder whether that was an oversight (in which case it should get a Fixes line) or an intentional choice due to issues? You mentioned hangup and open/close mismatches before... Thanks, Andreas [1] https://elinux.org/Device_Tree_Linux#FDT_built_into_kernel_as_data [2] https://patchwork.ozlabs.org/patch/983173/ [3] https://lists.infradead.org/pipermail/linux-lpwan/2019-January/69.html -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg)
Re: [PATCH lora-next 3/5] net: lora: sx130x: Add PicoCell serdev driver
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); > + serdev_device_set_parity(sdev, SERDEV_PARITY_NONE); > + serdev_device_set_flow_control(sdev, true); This should probably be false? https://github.com/Lora-net/picoGW_hal/blob/master/libloragw/src/loragw_com_linux.c#L65 tty.c_iflag &= ~(IXON | IXOFF | IXANY | ICRNL); ... tty.c_oflag &= ~(IXON | IXOFF | IXANY | ICRNL); Nothing that looks like RTS/CTS anywhere, which appears to be what the serdev implementation is switching with the above function. However, both true and false appeared to work equally so far. With one particular USB device I get the following warning/error, seemingly independent of whether I enable flow control above or not: [68640.481454] lora-picogw-usb 4-1:1.0: failed to set dtr/rts (imagine s/lora-picogw-usb/cdc_acm/ - cf. cdc-acm.c:acm_port_dtr_rts()) Looks like a firmware/hardware issue to me, since it appeared with the original cdc_acm driver on reboot, plus across reset, ports and hosts. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg)
Re: [PATCH lora-next 3/5] net: lora: sx130x: Add PicoCell serdev driver
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 sx130x.c. Since this serdev driver was using REGCACHE_NONE still and I don't spot a register missing as volatile either, I guess it may be a timing issue? My earlier locking patch is applied, to rule out any non-determinism in the register access order due to radio vs. concentrator interactions. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg)
