Re: [RFC net-next] net: fixed_phy: Move the DT based link GPIO parsing to of_mdio.c
Hi Andrew,
thanks for your feedback.
On Wed, Feb 06, 2019 at 10:53:22PM +0100, Andrew Lunn wrote:
> On Wed, Feb 06, 2019 at 12:51:06PM -0800, Moritz Fischer wrote:
> > Move the DT based link GPIO parsing to of_mdio and let the places
> > that register a fixed_phy pass in a GPIO descriptor or NULL.
> >
> > This allows fixed_phy on non-DT platforms to have link GPIOs, too.
> >
> > Signed-off-by: Moritz Fischer
> > ---
> > drivers/net/dsa/dsa_loop.c | 2 +-
> > drivers/net/ethernet/broadcom/bgmac.c| 2 +-
> > drivers/net/ethernet/broadcom/genet/bcmmii.c | 2 +-
> > drivers/net/phy/fixed_phy.c | 48 ++--
> > drivers/net/usb/lan78xx.c| 2 +-
> > drivers/of/of_mdio.c | 15 +-
> > include/linux/phy_fixed.h| 3 +-
> > 7 files changed, 23 insertions(+), 51 deletions(-)
> >
> > diff --git a/drivers/net/dsa/dsa_loop.c b/drivers/net/dsa/dsa_loop.c
> > index 17482ae09aa5..7f124c620092 100644
> > --- a/drivers/net/dsa/dsa_loop.c
> > +++ b/drivers/net/dsa/dsa_loop.c
> > @@ -343,7 +343,7 @@ static int __init dsa_loop_init(void)
> > unsigned int i;
> >
> > for (i = 0; i < NUM_FIXED_PHYS; i++)
> > - phydevs[i] = fixed_phy_register(PHY_POLL, &status, NULL);
> > + phydevs[i] = fixed_phy_register(PHY_POLL, &status, NULL, NULL);
> >
> > return mdio_driver_register(&dsa_loop_drv);
> > }
> > diff --git a/drivers/net/ethernet/broadcom/bgmac.c
> > b/drivers/net/ethernet/broadcom/bgmac.c
> > index 4632dd5dbad1..bce644dec5c2 100644
> > --- a/drivers/net/ethernet/broadcom/bgmac.c
> > +++ b/drivers/net/ethernet/broadcom/bgmac.c
> > @@ -1446,7 +1446,7 @@ int bgmac_phy_connect_direct(struct bgmac *bgmac)
> > struct phy_device *phy_dev;
> > int err;
> >
> > - phy_dev = fixed_phy_register(PHY_POLL, &fphy_status, NULL);
> > + phy_dev = fixed_phy_register(PHY_POLL, &fphy_status, NULL, NULL);
> > if (!phy_dev || IS_ERR(phy_dev)) {
> > dev_err(bgmac->dev, "Failed to register fixed PHY device\n");
> > return -ENODEV;
> > diff --git a/drivers/net/ethernet/broadcom/genet/bcmmii.c
> > b/drivers/net/ethernet/broadcom/genet/bcmmii.c
> > index 51880d83131a..7cbd737aba80 100644
> > --- a/drivers/net/ethernet/broadcom/genet/bcmmii.c
> > +++ b/drivers/net/ethernet/broadcom/genet/bcmmii.c
> > @@ -525,7 +525,7 @@ static int bcmgenet_mii_pd_init(struct bcmgenet_priv
> > *priv)
> > .asym_pause = 0,
> > };
> >
> > - phydev = fixed_phy_register(PHY_POLL, &fphy_status, NULL);
> > + phydev = fixed_phy_register(PHY_POLL, &fphy_status, NULL, NULL);
> > if (!phydev || IS_ERR(phydev)) {
> > dev_err(kdev, "failed to register fixed PHY device\n");
> > return -ENODEV;
> > diff --git a/drivers/net/phy/fixed_phy.c b/drivers/net/phy/fixed_phy.c
> > index d810f914aaa4..845bd7c2065a 100644
> > --- a/drivers/net/phy/fixed_phy.c
> > +++ b/drivers/net/phy/fixed_phy.c
> > @@ -18,6 +18,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -191,50 +192,12 @@ static void fixed_phy_del(int phy_addr)
> > }
> > }
> >
> > -#ifdef CONFIG_OF_GPIO
> > -static struct gpio_desc *fixed_phy_get_gpiod(struct device_node *np)
> > -{
> > - struct device_node *fixed_link_node;
> > - struct gpio_desc *gpiod;
> > -
> > - if (!np)
> > - return NULL;
> > -
> > - fixed_link_node = of_get_child_by_name(np, "fixed-link");
> > - if (!fixed_link_node)
> > - return NULL;
> > -
> > - /*
> > -* As the fixed link is just a device tree node without any
> > -* Linux device associated with it, we simply have obtain
> > -* the GPIO descriptor from the device tree like this.
> > -*/
> > - gpiod = gpiod_get_from_of_node(fixed_link_node, "link-gpios", 0,
> > - GPIOD_IN, "mdio");
> > - of_node_put(fixed_link_node);
> > - if (IS_ERR(gpiod)) {
> > - if (PTR_ERR(gpiod) == -EPROBE_DEFER)
> > - return gpiod;
> > - pr_err("error getting GPIO for fixed link %pOF, proceed
> > without\n",
> > -
[RFC net-next] net: fixed_phy: Move the DT based link GPIO parsing to of_mdio.c
Move the DT based link GPIO parsing to of_mdio and let the places
that register a fixed_phy pass in a GPIO descriptor or NULL.
This allows fixed_phy on non-DT platforms to have link GPIOs, too.
Signed-off-by: Moritz Fischer
---
drivers/net/dsa/dsa_loop.c | 2 +-
drivers/net/ethernet/broadcom/bgmac.c| 2 +-
drivers/net/ethernet/broadcom/genet/bcmmii.c | 2 +-
drivers/net/phy/fixed_phy.c | 48 ++--
drivers/net/usb/lan78xx.c| 2 +-
drivers/of/of_mdio.c | 15 +-
include/linux/phy_fixed.h| 3 +-
7 files changed, 23 insertions(+), 51 deletions(-)
diff --git a/drivers/net/dsa/dsa_loop.c b/drivers/net/dsa/dsa_loop.c
index 17482ae09aa5..7f124c620092 100644
--- a/drivers/net/dsa/dsa_loop.c
+++ b/drivers/net/dsa/dsa_loop.c
@@ -343,7 +343,7 @@ static int __init dsa_loop_init(void)
unsigned int i;
for (i = 0; i < NUM_FIXED_PHYS; i++)
- phydevs[i] = fixed_phy_register(PHY_POLL, &status, NULL);
+ phydevs[i] = fixed_phy_register(PHY_POLL, &status, NULL, NULL);
return mdio_driver_register(&dsa_loop_drv);
}
diff --git a/drivers/net/ethernet/broadcom/bgmac.c
b/drivers/net/ethernet/broadcom/bgmac.c
index 4632dd5dbad1..bce644dec5c2 100644
--- a/drivers/net/ethernet/broadcom/bgmac.c
+++ b/drivers/net/ethernet/broadcom/bgmac.c
@@ -1446,7 +1446,7 @@ int bgmac_phy_connect_direct(struct bgmac *bgmac)
struct phy_device *phy_dev;
int err;
- phy_dev = fixed_phy_register(PHY_POLL, &fphy_status, NULL);
+ phy_dev = fixed_phy_register(PHY_POLL, &fphy_status, NULL, NULL);
if (!phy_dev || IS_ERR(phy_dev)) {
dev_err(bgmac->dev, "Failed to register fixed PHY device\n");
return -ENODEV;
diff --git a/drivers/net/ethernet/broadcom/genet/bcmmii.c
b/drivers/net/ethernet/broadcom/genet/bcmmii.c
index 51880d83131a..7cbd737aba80 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmmii.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmmii.c
@@ -525,7 +525,7 @@ static int bcmgenet_mii_pd_init(struct bcmgenet_priv *priv)
.asym_pause = 0,
};
- phydev = fixed_phy_register(PHY_POLL, &fphy_status, NULL);
+ phydev = fixed_phy_register(PHY_POLL, &fphy_status, NULL, NULL);
if (!phydev || IS_ERR(phydev)) {
dev_err(kdev, "failed to register fixed PHY device\n");
return -ENODEV;
diff --git a/drivers/net/phy/fixed_phy.c b/drivers/net/phy/fixed_phy.c
index d810f914aaa4..845bd7c2065a 100644
--- a/drivers/net/phy/fixed_phy.c
+++ b/drivers/net/phy/fixed_phy.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -191,50 +192,12 @@ static void fixed_phy_del(int phy_addr)
}
}
-#ifdef CONFIG_OF_GPIO
-static struct gpio_desc *fixed_phy_get_gpiod(struct device_node *np)
-{
- struct device_node *fixed_link_node;
- struct gpio_desc *gpiod;
-
- if (!np)
- return NULL;
-
- fixed_link_node = of_get_child_by_name(np, "fixed-link");
- if (!fixed_link_node)
- return NULL;
-
- /*
-* As the fixed link is just a device tree node without any
-* Linux device associated with it, we simply have obtain
-* the GPIO descriptor from the device tree like this.
-*/
- gpiod = gpiod_get_from_of_node(fixed_link_node, "link-gpios", 0,
- GPIOD_IN, "mdio");
- of_node_put(fixed_link_node);
- if (IS_ERR(gpiod)) {
- if (PTR_ERR(gpiod) == -EPROBE_DEFER)
- return gpiod;
- pr_err("error getting GPIO for fixed link %pOF, proceed
without\n",
- fixed_link_node);
- gpiod = NULL;
- }
-
- return gpiod;
-}
-#else
-static struct gpio_desc *fixed_phy_get_gpiod(struct device_node *np)
-{
- return NULL;
-}
-#endif
-
struct phy_device *fixed_phy_register(unsigned int irq,
struct fixed_phy_status *status,
- struct device_node *np)
+ struct device_node *np,
+ struct gpio_desc *gpiod)
{
struct fixed_mdio_bus *fmb = &platform_fmb;
- struct gpio_desc *gpiod = NULL;
struct phy_device *phy;
int phy_addr;
int ret;
@@ -242,11 +205,6 @@ struct phy_device *fixed_phy_register(unsigned int irq,
if (!fmb->mii_bus || fmb->mii_bus->state != MDIOBUS_REGISTERED)
return ERR_PTR(-EPROBE_DEFER);
- /* Check if we have a GPIO associated with this fixed phy */
- gpiod = fixed_phy_get_gpiod(np);
- if (IS_ERR(gpiod))
TI Tiva Launchpad Luminary ICDI Bug
Hi! With a recent Update from Kernel 3.16.14-1-x86_64 to linux-3.17.1-1-x86_64 my machine isn't able anymore to recognise my TI Tiva Lauchpad. lsusb normally has the following entry: Bus 004 Device 010: ID 1cbe:00fd Luminary Micro Inc. In-Circuit Debug Interface It vanishes with 3.17. I downgraded to 3.16 and it works again. Bye pgp9gbQtDq2EB.pgp Description: PGP signature
Re: USB 3.0 SDR / Ettus Research B200/210
On Mon, Nov 4, 2013 at 4:27 PM, Alan Stern wrote: > A patch was proposed in the last couple of months to reduce kernel > overhead for transfers using libusb: > > http://marc.info/?l=linux-usb&m=138046339714340&w=2 > > The patch would need to be finished and all the relevant comments > addressed, and libusb might need some changes to match. Still, this > seems like it would be easier than writing your own kernel driver. Thanks for the input. I'll see what I can do. Cheers, Moritz -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB 3.0 SDR / Ettus Research B200/210
On Mon, Nov 4, 2013 at 2:21 PM, Greg KH wrote: > Where specifically in the kernel? Busywaiting for data transferrs to > complete, or doing something else? Are you keeping the pipeline full to > the device? You should be able to hit USB "line speed" from userspace > if you just are reading/writing bulk data with enough transferrs in > flight. I'll confirm this with my colleagues. Sorry I wasn't really verbose enough here. > That's a good place to start, but it really depends on what type of > interface you want to expose to userspace, as to what the best driver to > base off of would be. I was thinking about a simple char / misc device with a read / write / ioctl or sysfs interface. The userland part would again be provided by UHD as with our ethernet devices. > As you are a ADC/DAC, you probably want to tie into the comedi > subsystem, so take a look at the USB drivers in the > drivers/staging/comedi/ subdirectories for an example of what to use. Thanks a lot already for your quick response. I'll read up on comedi and see if it fits our use case, and hopefully come back with some code to look at ;-) Cheers, Moritz -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
USB 3.0 SDR / Ettus Research B200/210
Hi guys, This is my first post to this list, so let me quickly introduce myself. I'm a software engineer for Ettus Research (National Instruments). One of our new products [1] is a USB 3.0 (using Cypress FX3) based SDR that currently ships with a libusb based open source driver integrated in our open source UHD userland driver. Our device comes with ADC/DACs that need high throughput streaming from and to the host. We're using bulk transfers to send data to a Spartan 6 FPGA in the device. As the CPU usage is quite high and the throughput using libusb is not as high as we expect we're currently looking into developing a kernel driver. Profiling showed we're spending quite some time in the kernel when using libusb. I've started grepping around the tree for an example to steal from and stumbled upon the drivers/usb/usb-skeleton.c file. Can I base a high throughput (streaming) USB 3.0 driver off of this or is this not a good starting point to look at? Are there other device drivers to look at that might give me some insight into how to deal with super speed devices using bulk transfers? If there is nothing to look at (yet) I'm happy to work on this and contribute our solution back. Cheers, Moritz [1] https://www.ettus.com/product/details/UB210-KIT -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
