Re: [PATCH net-next v2 0/2] of: mdio: Fall back to mdiobus_register() with NULL device_node

On Wed, May 16, 2018 at 10:54:12AM +0200, Geert Uytterhoeven wrote: > Hi Florian, > > Thanks for your series! > I like the effect on simplifying drivers. > > On Wed, May 16, 2018 at 1:56 AM, Florian Fainelli > wrote: > > This patch series updates of_mdiobus_register()

Re: [PATCH v3 3/3] dt-bindings: Document the DT bindings for lan78xx

applications without an EEPROM or programmed OTP. > > Document the supported properties in a bindings file. > > Signed-off-by: Phil Elwell <p...@raspberrypi.org> Reviewed-by: Andrew Lunn <and...@lunn.ch> Andrew -- To unsubscribe from this list: send the line "unsubs

Re: [PATCH v3 2/3] lan78xx: Read LED states from Device Tree

+ (len > 3) * HW_CFG_LED3_EN_; > + lan78xx_write_reg(dev, HW_CFG, reg); > + } > + } > + Humm. Not nice. But i cannot think of a cleaner way of doing this. Reviewed-by: Andrew Lunn <and...@lunn.ch> Andrew -- To

Re: [PATCH v2 2/3] lan78xx: Read LED states from Device Tree

On Wed, Apr 18, 2018 at 04:45:22PM +0100, Phil Elwell wrote: > Add support for DT property "microchip,led-modes", a vector of zero > to four cells (u32s) in the range 0-15, each of which sets the mode > for one of the LEDs. Some possible values are: > > 0=link/activity

Re: [PATCH 3/4] lan78xx: Read LED modes from Device Tree

> @@ -2097,6 +2098,25 @@ static int lan78xx_phy_init(struct lan78xx_net *dev) > (void)lan78xx_set_eee(dev->net, ); > } > > + if (!of_property_read_u32_array(dev->udev->dev.of_node, > + "microchip,led-modes", > +

Re: [PATCH 4/4] dt-bindings: Document the DT bindings for lan78xx

On Thu, Apr 12, 2018 at 02:55:36PM +0100, Phil Elwell wrote: > The Microchip LAN78XX family of devices are Ethernet controllers with > a USB interface. Despite being discoverable devices it can be useful to > be able to configure them from Device Tree, particularly in low-cost > applications

Re: [PATCH 3/4] lan78xx: Read LED modes from Device Tree

On Thu, Apr 12, 2018 at 02:55:35PM +0100, Phil Elwell wrote: > Add support for DT property "microchip,led-modes", a vector of two > cells (u32s) in the range 0-15, each of which sets the mode for one > of the two LEDs. Some possible values are: > > 0=link/activity 1=link1000/activity

Re: [PATCH 4/4] dt-bindings: Document the DT bindings for lan78xx

On Thu, Apr 12, 2018 at 03:10:57PM +0100, Phil Elwell wrote: > Hi Andrew, > > On 12/04/2018 15:04, Andrew Lunn wrote: > > On Thu, Apr 12, 2018 at 02:55:36PM +0100, Phil Elwell wrote: > >> The Microchip LAN78XX family of devices are Ethernet controllers with > >&g

Re: [PATCH 2/4] lan78xx: Read initial EEE setting from Device Tree

On Thu, Apr 12, 2018 at 02:55:34PM +0100, Phil Elwell wrote: > Add two new Device Tree properties: > * microchip,eee-enabled - a boolean to enable EEE > * microchip,tx-lpi-timer - time in microseconds to wait after TX goes >idle before entering the low power state >

Re: [PATCH 1/4] lan78xx: Read MAC address from DT if present

Hi Phil > - ret = lan78xx_write_reg(dev, RX_ADDRL, addr_lo); > - ret = lan78xx_write_reg(dev, RX_ADDRH, addr_hi); > + mac_addr = of_get_mac_address(dev->udev->dev.of_node); It might be better to use the higher level

Re: [PATCH 4/4] dt-bindings: Document the DT bindings for lan78xx

On Thu, Apr 12, 2018 at 02:55:36PM +0100, Phil Elwell wrote: > The Microchip LAN78XX family of devices are Ethernet controllers with > a USB interface. Despite being discoverable devices it can be useful to > be able to configure them from Device Tree, particularly in low-cost > applications

Re: [PATCH] lan78xx: Correctly indicate invalid OTP

On Wed, Apr 11, 2018 at 10:59:17AM +0100, Phil Elwell wrote: > lan78xx_read_otp tries to return -EINVAL in the event of invalid OTP > content, but the value gets overwritten before it is returned and the > read goes ahead anyway. Make the read conditional as it should be > and preserve the error

Re: [Question] MFD driver that handles clocks/resets and populates child nodes

On Mon, Apr 02, 2018 at 10:21:01PM +0900, Masahiro Yamada wrote: > 2018-04-02 21:04 GMT+09:00 Andrew Lunn <and...@lunn.ch>: > >> The maintainer of DWC3, Felipe Balbi, requested to > >> split the glue layer driver into small parts such as > >> reset, regulator

Re: [Question] MFD driver that handles clocks/resets and populates child nodes

> The maintainer of DWC3, Felipe Balbi, requested to > split the glue layer driver into small parts such as > reset, regulator, phy, etc. What exactly did Felipe ask for? Did he ask that the patch be split up, one patch per reset, regulator, phy etc? Are all these resources used just by the

Re: [PATCH] lan78xx: Connect phy early

> @@ -2082,8 +2082,6 @@ static int lan78xx_phy_init(struct lan78xx_net *dev) > > dev->fc_autoneg = phydev->autoneg; > > - phy_start(phydev); > - > netif_dbg(dev, ifup, dev->net, "phy initialised successfully"); > > return 0; > @@ -2512,9 +2510,7 @@ static int

Re: [PATCH 0/2] net/usb/ax88179_178a: Adjustments for ax88179_chk_eee()

On Sat, Mar 10, 2018 at 07:22:55PM +0100, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sat, 10 Mar 2018 19:05:45 +0100 > > Two update suggestions were taken into account > from static source code analysis. Hi Markus How about re-writing this driver to

Re: [PATCH] net/{mii,smsc}: Make mii_ethtool_get_link_ksettings and smc_netdev_get_ecmd return void

> diff --git a/drivers/net/cris/eth_v10.c b/drivers/net/cris/eth_v10.c > index da02041..017f48c 100644 > --- a/drivers/net/cris/eth_v10.c > +++ b/drivers/net/cris/eth_v10.c > @@ -1417,10 +1417,9 @@ static int e100_get_link_ksettings(struct net_device > *dev, > { > struct net_local *np =

Re: [PATCH v3] smsc95xx: Add comments to the registers definition

Microchip Linux Driver Support <unglinuxdri...@microchip.com> > CC: David Miller <da...@davemloft.net> > Signed-off-by: Martin Wetterwald <mar...@wetterwald.eu> Reviewed-by: Andrew Lunn <and...@lunn.ch> Andrew -- To unsubscribe from this list: send the line "uns

Re: [PATCH] smsc95xx: Add comments to the registers definition

Hi Martin > @@ -2032,7 +2032,7 @@ static struct sk_buff *smsc95xx_tx_fixup(struct usbnet > *dev, > skb_push(skb, 4); > tx_cmd_b = (u32)(skb->len - 4); > if (csum) > - tx_cmd_b |= TX_CMD_B_CSUM_ENABLE; > + tx_cmd_b |= TX_CMD_B_CSUM_EN; This changed seems

Re: [PATCH RFC 0/7] phylib MMD accessor cleanups

> Thanks. When I posted this last time around (19th Jan) I mentioned > about marking the old _indirect() accessors with __deprecated - is > that still something we want to do? > > I haven't tested this against net-next yet, so I don't know if there > are any new users of the indirect accessors -

Re: [PATCH RFC 3/7] net: lan78xx: update for phy_(read|write)_mmd_indirect() removal

On Sun, Mar 19, 2017 at 11:00:29AM +, Russell King wrote: > lan78xx appears to use phylib in a rather weird way, accessing the PHY > partly through phylib, and partly by makign direct accesses to it, Hi Russell s/makign/making Andrew -- To unsubscribe from this list: send the line

Re: [PATCH RFC 0/7] phylib MMD accessor cleanups

function name. Same > applies for the write methods. Hi Russell This all looks good, apart from the one typo i spotted. Reviewed-by: Andrew Lunn <and...@lunn.ch> Andrew -- 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: [PATCH v2 0/3] Add EHCI support for Armada 37xx

tep is > needed: this is the purpose of the first patch. > > The second patch allows to build the driver for the ARM64 Armada SoCs. > > The last one enables the EHCI in the device tree. > > This second version takes into account the review from Andrew Lunn and > Thomas Petazzoni. Hi

Re: [PATCH 2/3] usb: host: Allow to build ehci orion with mvebu SoCs

On Wed, Mar 08, 2017 at 05:24:22PM +0100, Gregory CLEMENT wrote: > The mvebu ARM64 SoCs no more select PLAT_ORION but some of them as the > Armada 37xx use the EHCI orion controller. This patch allow to build > the driver when ARCH_MVEBU is selected. The mvebu ARM64 SoCs no longer selects

Re: [PATCH 1/3] usb: orion-echi: Add support for the Armada 3700

Hi Gregory > - Add a new compatoble string for the Armada 3700 SoCs compatible > > - add sbuscfg support for orion usb controller driver. For the SoCs > without hlock, need to program BAWR/BARD/AHBBRST fields in the sbuscfg > register to guarantee the AHB master's burst would not overrun

Re: [PATCH v6] r8152: Add support for setting pass through MAC address on RTL8153-AD

> > It is same, how to handle two network cards which tell us, that they > > have same MAC addresses. > > > > The kernel handles this just fine. In doing this patch I checked to see > what it does in that scenario. Two devices are made. systemd doesn't > rename the second device via the MAC

Re: [PATCH v6] r8152: Add support for setting pass through MAC address on RTL8153-AD

t; --- > > Changes from v5: > > * Correct return value if hex2bin succesful but invalid ether addr > > Have things calmed down enough now that I can apply this? Hi David I think the code has reaching the level of maturity needed for acceptance. So for the code quality: Revi

Re: [PATCH v3] r8152: Add support for setting pass through MAC address on RTL8153-AD

> + /* returns _AUXMAC_#AABBCCDDEEFF# */ > + status = acpi_evaluate_object(NULL, "\\_SB.AMAC", NULL, ); > + obj = (union acpi_object *)buffer.pointer; > + if (ACPI_SUCCESS(status)) { > + if (obj->type != ACPI_TYPE_BUFFER || > + obj->string.length !=

Re: [PATCH v2] r8152: Add support for setting MAC to system's Auxiliary MAC address

On Thu, Jun 02, 2016 at 07:04:32PM +, mario_limoncie...@dell.com wrote: > > -Original Message- > > From: Andrew Lunn [mailto:and...@lunn.ch] > > Sent: Thursday, June 2, 2016 2:03 PM > > To: Limonciello, Mario <mario_limoncie...@dell.com> > > Cc

Re: [PATCH v2] r8152: Add support for setting MAC to system's Auxiliary MAC address

> > And you want to check this for all Dell devices? Please be model > > specific, I doubt a bunch of Dell servers wants to run this code... > > > > Tracking model specific is really going to turn into a giant list never > ending list. > To drill down more specifically, I can match on chassis

Re: [PATCH] r8152: Add support for setting MAC to system's Auxiliary MAC address

> > > > > + pr_info("r8152: Using system auxiliary MAC address"); > > > > It would be great to write also mac address into that pr_info And since there could be multiple r8152 in the system, it would be good to indicate which of them is having its MAC changed. So netdev_info() or

Re: [PATCH] r8152: Add support for setting MAC to system's Auxiliary MAC address

On Wed, Jun 01, 2016 at 04:50:44PM -0500, Mario Limonciello wrote: > Dell systems with Type-C ports have support for a persistent system > specific MAC address when used with Dell Type-C docks and dongles. > This means a dock plugged into two different systems will show different > (but

Re: [REGRESSION] asix: Lots of asix_rx_fixup() errors and slow transmissions

> In other words, the full-speed hub is restricting the USB to > Ethernet Adaptor to a 12Mbps (half-duplex) bandwidth to support > Ethernet 100Mbps (full-duplex) traffic. That is not going to work > very well because Ethernet frames (perhaps partial Ethernet frames) > need to be discarded within

Re: [PATCH 1/3] usb: core: add power sequence for USB devices

> So, would you like to accept the generic solution like below: > > - Create a generic power sequence driver, and it will be probed > according to compatible string at device tree. At its probe, > we can create a power sequence structure, and let this structure > as the private data for this

Re: [PATCH 1/3] usb: core: add power sequence for USB devices

On Fri, Mar 04, 2016 at 10:02:42AM +0800, Peter Chen wrote: > On Thu, Mar 03, 2016 at 02:54:55PM -0600, Rob Herring wrote: > > On Thu, Mar 3, 2016 at 4:01 AM, Peter Chen wrote: > > > Some hard-wired USB devices need to do power sequence to let the > > > device work normally,

Re: [PATCH 2/3] usb: chipidea: host: let the hcd know's parent device node

> > > diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c > > > index 053bac9..55120ef 100644 > > > --- a/drivers/usb/chipidea/host.c > > > +++ b/drivers/usb/chipidea/host.c > > > @@ -109,15 +109,25 @@ static int host_start(struct ci_hdrc *ci) > > > struct ehci_hcd *ehci; > >

Re: [PATCH 2/3] usb: chipidea: host: let the hcd know's parent device node

On Thu, Mar 03, 2016 at 06:01:15PM +0800, Peter Chen wrote: > From: Peter Chen > > Since the hcd (chipidea core device) has no device node, so > if we want to describe the child node under the hcd, we had > to put it under its parent's node (glue layer device), and > in

Re: [PATCH] asix: do not free array priv->mdio->irq

ue detected using static analysis with CoverityScan > > Fixes: e7f4dc3536a400 ("mdio: Move allocation of interrupts into core") > Signed-off-by: Colin Ian King <colin.k...@canonical.com> Reviewed-by: Andrew Lunn <and...@lunn.ch> Thanks Andrew > --- > drivers/net

Re: [ehci-orion] ETIMEOUT with ehci_setup()'s ehci_halt()

One final update on this topic: the kernel config was missing the CONFIG_USB_EHCI_ROOT_HUB_TT option. It turns out that the USB IP embeded a Transaction Translator and there is a check in ehci_halt() that aborts the routine in case of a Transaction Translator in the ehci controller. The check

Re: [ehci-orion] ETIMEOUT with ehci_setup()'s ehci_halt()

On Fri, Jun 05, 2015 at 04:34:54PM +0200, Valentin Longchamp wrote: Hello, I am currently bringing up the USB 2.0 Host controller of the Bobcat's (98DX4122 Marvell switch) internal kirkwood CPU on a variation of Keymile's km_kirwood hardware (kirkwood-km_kirkwood.dts). When the driver

Re: [RFC PATCH 0/3] Enable connecting DSA-based switch to the USB RMII interface.

On Wed, Apr 22, 2015 at 04:14:33PM +, Jan Kaisrlik wrote: 2015-04-21 17:51 GMT+00:00 Florian Fainelli f.faine...@gmail.com: On 21/04/15 10:39, Andrew Lunn wrote: I would however say that sysfs is the wrong API. The linux network stack uses netlink for most configuration activities. So i

Re: [RFC PATCH 0/3] Enable connecting DSA-based switch to the USB RMII interface.

I would however say that sysfs is the wrong API. The linux network stack uses netlink for most configuration activities. So i would suggest adding a netlink binding to DSA, and place the code in net/dsa/, not within an MDIO driver. I suppose we could do that, but that sounds like a

Re: [RFC PATCH 0/3] Enable connecting DSA-based switch to the USB RMII interface.

My goal in reworking this weird DSA device/driver model is that you could just register your switch devices as an enhanced phy_driver/spi_driver/pci_driver etc..., such that libphy-ready drivers could just take advantage of that when they scan/detect their MDIO buses and find a switch. We are

Re: [RFC PATCH 0/3] Enable connecting DSA-based switch to the USB RMII interface.

Hi Jan Interesting work, but i think the architecture is wrong. DSA needs an Ethernet device, an MDIO bus, and information about ports on the switch. The MDIO bus and the Ethernet need no knowledge of DSA. So putting your DSA configuration code in the MDIO driver is wrong. The problem you have

Re: [PATCH v2 0/3] ARM: mvebu: Enable XHCI on the Armada 385 AP

On Tue, Jan 20, 2015 at 09:30:28PM +0100, Maxime Ripard wrote: Hi Andrew, On Mon, Jan 19, 2015 at 10:35:07PM +0100, Andrew Lunn wrote: On Mon, Jan 19, 2015 at 02:01:11PM +0100, Maxime Ripard wrote: Hi all, This serie enables the Armada 385 AP XHCI controller. Since

Re: [PATCH v2 0/3] ARM: mvebu: Enable XHCI on the Armada 385 AP

On Mon, Jan 19, 2015 at 02:01:11PM +0100, Maxime Ripard wrote: Hi all, This serie enables the Armada 385 AP XHCI controller. Since the controller uses a GPIO-controlled VBUS, we used the phy-generic driver, and made the needed additions to the xhci-plat driver to retrieve a USB phy.

Re: [PATCH v3 01/12] reset: add the Berlin reset controller driver

On Wed, Jul 16, 2014 at 10:25:55AM +0200, Antoine Ténart wrote: Add a reset controller for Marvell Berlin SoCs which is used by the USB PHYs drivers (for now). Signed-off-by: Antoine Ténart antoine.ten...@free-electrons.com Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com

Re: [PATCH 2/5] Documentation: dt-bindings: document the Armada 375 USB cluster binding

On Fri, May 23, 2014 at 02:54:02PM +0530, Kishon Vijay Abraham I wrote: Hi, On Friday 16 May 2014 09:52 PM, Gregory CLEMENT wrote: Armada 375 comes with an USB2 host and device controller and an USB3 controller. The USB cluster control register allows to manage common features of both

Re: [PATCH 2/5] Documentation: dt-bindings: document the Armada 375 USB cluster binding

Do you want one .txt file per driver, or can we combine binding documentations into one file? There should already be a mvebu-phy.txt, which contains the sata phy usable on some of the Armada SoC families. This binding could be appended to it. Ah. Humm, well! It seems the patch adding the

Re: [PATCH 2/5] Documentation: dt-bindings: document the Armada 375 USB cluster binding

On Fri, May 23, 2014 at 07:22:48PM +0530, Kishon Vijay Abraham I wrote: hI, On Friday 23 May 2014 07:06 PM, Andrew Lunn wrote: Do you want one .txt file per driver, or can we combine binding documentations into one file? There should already be a mvebu-phy.txt, which contains the sata

Re: [PATCH v3 02/20] usb: ehci-orion: Add the optional PHY support

On Wed, May 07, 2014 at 11:40:06AM +0200, Thomas Petazzoni wrote: Dear Andrew Lunn, On Tue, 6 May 2014 15:33:41 +0200, Andrew Lunn wrote: + priv-phy = devm_phy_get(pdev-dev, usb); + if (!IS_ERR(priv-phy)) { + err = phy_init(priv-phy); + if (err

Re: [PATCH v3 02/20] usb: ehci-orion: Add the optional PHY support

On Tue, May 06, 2014 at 02:13:57AM +0200, Gregory CLEMENT wrote: This commit allows to use the PHY provided through the device tree. It will be useful for the Armada 375 SoCs. if no PHY is provided then the behavior of the driver is unchanged. Signed-off-by: Gregory CLEMENT

Re: [PATCH v3 08/20] ARM: mvebu: Add Device Tree description of xHCI hosts on Armada 38x

On Tue, May 06, 2014 at 02:14:03AM +0200, Gregory CLEMENT wrote: The Marvell Armada 38x SoCs contains two xHCI host. This commit adds the Device Tree description of those interfaces at the SoC level, and also enables the two USB3 ports on the Armada 385 DB platform and one USB3 port on the

Re: [PATCH v3 17/20] phy: Add support for USB cluster on the Armada 375 SoC

On Tue, May 06, 2014 at 02:14:12AM +0200, Gregory CLEMENT wrote: The Armada 375 SoC comes with an USB2 host and device controller and an USB3 controller. The USB cluster control register allows to manage common features of both USB controllers. It uses the generic PHY framework

Re: [PATCH v2 02/18] usb: host: xhci-plat: Add clocks support

On Fri, Apr 25, 2014 at 04:07:00PM +0200, Gregory CLEMENT wrote: Some platform (such as the Armada 38x ones) can gate the clock of their USB controller. This patch add the support for the clock, by enabling them during probe and disabling them on remove. As not all platforms have clock

Re: [PATCH v2 14/18] ARM: mvebu: Add support for USB cluster on the Armada 375 SoC

+* We can't use usb2 and usb3 in the same time, so let's +* disbale usb2 and complain about it to the user askinf typos: disable, asking And it should be at the same time, not in. Andrew -- To unsubscribe from this list: send the line

Re: [PATCH v2 05/18] ARM: mvebu: Add Device Tree description of xHCI hosts on Armada 38x

On Fri, Apr 25, 2014 at 04:07:03PM +0200, Gregory CLEMENT wrote: The Marvell Armada 38x SoCs contain two xHCI host. This commit adds the Device Tree description of those interfaces at the SoC level, and also enables the two USB3 ports on the Armada 385 DB platform and one USB3 port on the

Re: [PATCH v2 14/18] ARM: mvebu: Add support for USB cluster on the Armada 375 SoC

On Fri, Apr 25, 2014 at 04:07:12PM +0200, Gregory CLEMENT wrote: The Armada 375 SoC comes with an USB2 host and device controller and an USB3 controller. The USB cluster control register allows to manage common features of both USB controllers. Signed-off-by: Gregory CLEMENT

Re: [PATCH v8 2/2] usb-serial: Moxa UPORT 12XX/14XX/16XX driver

I hope it's OK that I submit the patch with the below changes to Greg for inclusion in v3.14. Let me know if you prefer to respin yourself. Hi Johan The patch looks good. Acked-by: Andrew Lunn and...@lunn.ch Thanks for all your work with fixing up and mainlining this driver! And thanks

[PATCH v8 2/2] usb-serial: Moxa UPORT 12XX/14XX/16XX driver

. This is optional and the driver appears to work O.K. with older firmware in the devices ROM. This driver is based on the MOXA driver and retains MOXAs copyright. Signed-off-by: Andrew Lunn and...@lunn.ch --- v1-v2 Remove debug module parameter. Add missing \n to dev_dbg() strings. Consistent dev_dbg(%s

[PATCH v8 1/2] tty: Add C_CMSPAR(tty)

Add the missing C_CMSPAR(tty) macro. Signed-off-by: Andrew Lunn and...@lunn.ch --- include/linux/tty.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/tty.h b/include/linux/tty.h index 97d660ed70c1..e53e90ed3f19 100644 --- a/include/linux/tty.h +++ b/include/linux/tty.h

Re: [PATCH v7 2/2] usb-serial: Moxa UPORT 12XX/14XX/16XX driver

+* endpoint, with a multiplex header. The second bulk in is +* used for events. Throw away all but the first two bulk in +* urbs. +*/ + for (i = 2; i serial-num_bulk_in; ++i) { + port = serial-port[i]; + for (j = 0; j

[PATCH v7 1/2] tty: Add C_CMSPAR(tty)

Add the missing C_CMSPAR(tty) macro. Signed-off-by: Andrew Lunn and...@lunn.ch --- include/linux/tty.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/tty.h b/include/linux/tty.h index 97d660ed70c1..e53e90ed3f19 100644 --- a/include/linux/tty.h +++ b/include/linux/tty.h

[PATCH v7 2/2] usb-serial: Moxa UPORT 12XX/14XX/16XX driver

. This is optional and the driver appears to work O.K. with older firmware in the devices ROM. This driver is based on the MOXA driver and retains MOXAs copyright. Signed-off-by: Andrew Lunn and...@lunn.ch --- v1-v2 Remove debug module parameter. Add missing \n to dev_dbg() strings. Consistent dev_dbg(%s

[PATCH v6 2/2] usb-serial: Moxa UPORT 12XX/14XX/16XX driver

. This is optional and the driver appears to work O.K. with older firmware in the devices ROM. This driver is based on the MOXA driver and retains MOXAs copyright. Signed-off-by: Andrew Lunn and...@lunn.ch --- v1-v2 Remove debug module parameter. Add missing \n to dev_dbg() strings. Consistent dev_dbg(%s

[PATCH v6 1/2] tty: Add C_CMSPAR(tty)

Add the missing C_CMSPAR(tty) macro. Signed-off-by: Andrew Lunn and...@lunn.ch --- include/linux/tty.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/tty.h b/include/linux/tty.h index 64f864651d86..8d1ba896070a 100644 --- a/include/linux/tty.h +++ b/include/linux/tty.h

Re: [PATCH v5 2/2] usb-serial: Moxa UPORT 12XX/14XX/16XX driver

Hi Johan Thanks for the quick response. +static int mxuport_dtr(struct usb_serial_port *port, int on) +{ + struct mxuport_port *mxport = usb_get_serial_port_data(port); + int err; + + mutex_lock(mxport-mutex); + + if (on) + mxport-mcr_state |= UART_MCR_DTR;

[PATCH v5 1/2] tty: Add C_CMSPAR(tty)

Add the missing C_CMSPAR(tty) macro. Signed-off-by: Andrew Lunn and...@lunn.ch --- include/linux/tty.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/tty.h b/include/linux/tty.h index 64f864651d86..8d1ba896070a 100644 --- a/include/linux/tty.h +++ b/include/linux/tty.h

[PATCH v5 2/2] usb-serial: Moxa UPORT 12XX/14XX/16XX driver

. This is optional and the driver appears to work O.K. with older firmware in the devices ROM. This driver is based on the MOXA driver and retains MOXAs copyright. Signed-off-by: Andrew Lunn and...@lunn.ch --- v1-v2 Remove debug module parameter. Add missing \n to dev_dbg() strings. Consistent dev_dbg(%s

Re: [PATCH] usb-serial: Moxa UPORT 12XX/14XX/16XX driver

Hopefully my comments will suffice as guidance for mxuport, but we could iterate the flow-control handling separate from the other changes if you want. Hi Johan I just posted v5. It would be good if you could take a look at the flow-control changes first. Thanks Andrew -- To

Re: [PATCH] usb-serial: Moxa UPORT 12XX/14XX/16XX driver

Hi Johan Thanks for the review. I have a few questions, points to raise. + /* Submit the vendor request */ + buf[0] = data_bits; + buf[1] = parity; + buf[2] = stop_bits; + buf[3] = 0; + + err = mxuport_send_ctrl_data_urb(serial, RQ_VENDOR_SET_LINE, +

[PATCH] usb-serial: Moxa UPORT 12XX/14XX/16XX driver

. This is optional and the driver appears to work O.K. with older firmware in the devices ROM. This driver is based on the MOXA driver and retains MOXAs copyright. Signed-off-by: Andrew Lunn and...@lunn.ch --- v1-v2 Remove debug module parameter. Add missing \n to dev_dbg() strings. Consistent dev_dbg(%s

Re: [PATCH v3] usb-serial: Moxa UPORT 12XX/14XX/16XX driver

On Tue, Oct 15, 2013 at 08:30:51AM +, Danny Lin (林政易) wrote: Hi Andrew, We can do the interface testing but I want to know how to get the latest source. We need about 5 days to do the testing for all models and give you a testing report. Hi Danny Thanks for the offer of testing.

Re: [PATCH v3] usb-serial: Moxa UPORT 12XX/14XX/16XX driver

On Wed, Oct 09, 2013 at 07:27:42PM +0200, Johan Hovold wrote: On Wed, Oct 09, 2013 at 12:57:45PM +0200, Johan Hovold wrote: On Wed, Sep 25, 2013 at 11:53:00AM +0200, Andrew Lunn wrote: [...] +#define MX_INT_RS232 0 +#define MX_INT_2W_RS485 1 +#define

[PATCH v3] usb-serial: Moxa UPORT 12XX/14XX/16XX driver

. If the available version is newer, it will be download into RAM of the device and started. This is optional and the driver appears to work O.K. with older firmware in the devices ROM. This driver is based on the MOXA driver and retains MOXAs copyright. Signed-off-by: Andrew Lunn and...@lunn.ch --- v1-v2

Re: [PATCH v2] usb-serial: Moxa UPORT 12XX/14XX/16XX driver

I need 115200, since that is what most of my development systems use for the serial console. Will the normal path, tty_get_baud_rate(tty), handle baud rates above 57600? Yes, cfsetospeed can be used up to 4Mbaud for example. The hardware is also capable of custom divisor although you

Re: [PATCH v2] usb-serial: Moxa UPORT 12XX/14XX/16XX driver

Hi Johan Thanks for your quick comments. I hopefully have more time to work on this code now, so v3 will not take as long as v2 did. All data transfers are made on port0, yet the locks are taken on PortN. urb-context points to PortN, even though the URL is for port0. You probably meant

[Pull request] Fix moxa firmware filenames

Hi David, Ben. I messed up with the Moxa firmware. I have the filenames wrong, due to one too many decimal to hex conversions of the USB product ID. I could work around this in the driver, but it would be a lot better to rename the files. Here is a pull request to fix the issue. Thanks

Re: [PULL] Moxa UPort firmware

On Thu, Aug 08, 2013 at 11:00:20PM +0200, Ben Hutchings wrote: On Thu, 2013-08-08 at 12:20 +0200, Andrew Lunn wrote: Hi Ben, David Here is a pull request for firmware for Moxa USB-Serial hub devices. Thanks Andrew The following changes since commit

[PULL] Moxa UPort firmware

at: https://github.com/lunn/linux-firmware.git moxa for you to fetch changes up to 6eed67a9f372a5ade30431af9af0aff8df6f678f: moxa: Add firmware for some of the Moxa USB-Serial hubs (2013-08-08 12:04:52 +0200) Andrew Lunn (1): moxa

Re: [PATCH 2/2] usb-serial: Moxa UPORT 12XX/14XX/16XX driver

On Sun, May 26, 2013 at 06:04:24PM +0200, Johan Hovold wrote: On Sun, May 26, 2013 at 01:00:51PM +0200, Andrew Lunn wrote: +/* + * mxuport_write_room + * + * Return how much space is available in the buffer. + */ +static int mxuport_write_room(struct tty_struct *tty) +{ + struct

Re: [PATCH 2/2] usb-serial: Moxa UPORT 12XX/14XX/16XX driver

On Tue, May 28, 2013 at 11:08:54PM +0200, Johan Hovold wrote: On Tue, May 28, 2013 at 09:41:08PM +0200, Andrew Lunn wrote: On Sun, May 26, 2013 at 06:04:24PM +0200, Johan Hovold wrote: On Sun, May 26, 2013 at 01:00:51PM +0200, Andrew Lunn wrote: +/* + * mxuport_write_room

[PATCH 0/2] MOXA UPORT Serial USB driver

These two patches add support for MOXA 12XX/14XX/16XX USB serial devices. The first patch exports a function from the generic usb serial driver, which the driver in the second patch would like to use. Andrew Lunn (2): USB: Serial: export usb_serial_generic_submit_read_urb() usb-serial: Moxa

[PATCH 1/2] USB: Serial: export usb_serial_generic_submit_read_urb()

usable within generic functions, in particular usb_serial_generic_read_bulk_callback(). Export this function so drivers can use it in there own read bulk callback routine. Signed-off-by: Andrew Lunn and...@lunn.ch --- drivers/usb/serial/generic.c |5 +++-- include/linux/usb/serial.h |2

Re: [PATCH 2/2] usb-serial: Moxa UPORT 12XX/14XX/16XX driver

On Sun, May 26, 2013 at 06:04:24PM +0200, Johan Hovold wrote: On Sun, May 26, 2013 at 01:00:51PM +0200, Andrew Lunn wrote: Add a driver which supports the following Moxa USB to serial converters: * 2 ports : UPort 1250, UPort 1250I * 4 ports : UPort 1410, UPort 1450, UPort 1450I

Re: [PATCH 2/2] USB: EHCI: make ehci-orion a separate driver

On Mon, Feb 18, 2013 at 05:34:35PM -0500, Alan Stern wrote: On Fri, 15 Feb 2013, Arnd Bergmann wrote: From: Manjunath Goudar manjunath.gou...@linaro.org With the multiplatform changes in arm-soc tree, it becomes possible to enable the mvebu platform (which uses ehci-orion) at the

Re: [PATCH 2/2] USB: EHCI: make ehci-orion a separate driver

into a separate module, as we do here for the orion bus glue. Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Jason Cooper ja...@lakedaemon.net Cc: Andrew Lunn and...@lunn.ch --- drivers/usb/host/Kconfig | 8 drivers/usb/host

[PATCH v2 2/2] ARM: Kirkwood: Convert all DT boards to EHCI via DT.

Now that the EHCI driver has DT support, drop old style configuration of it and add DT in its place. Since all the boards enable the EHCI, enable it by default in kirkwood.dtsi. Any new boards which don't have USB can specifically disable it. Signed-off-by: Andrew Lunn and...@lunn.ch --- arch

Re: [PATCH 1/2] ARM: Kirkwood: ehci-orion: Add device tree binding

+Required properties: +- compatible: must be marvell,orion-ehci +- reg: physical base address of the controller and length of memory mapped + region. +- interrupts: The EHCI interrupt +- phy-version: Can be one of: + NA - Don't touch the phy, something else has already configured

[PATCH] USB: PLAT_ORION fulfils USB_ARCH_HAS_EHCI

The various Orion SoCs, i.e. orion5x, kirkwood, dove, mv78xx0 and 370/XP have EHCI. Make sure USB_ARCH_HAS_EHCI reflects this. Reported-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com Signed-off-by: Andrew Lunn and...@lunn.ch --- drivers/usb/Kconfig |1 + 1 file changed, 1

[PATCH 1/2] ARM: Kirkwood: ehci-orion: Add device tree binding

Based on previous work by Michael Walle and Jason Cooper. Made their work actually work, which required added interrupt from DT and auxdata, along with setting the dma_mask, which DT does not currently do. Signed-off-by: Andrew Lunn and...@lunn.ch --- .../devicetree/bindings/usb/ehci-orion.txt

[PATCH 2/2] ARM: Kirkwood: Convert all DT boards to EHCI via DT.

Now that the EHCI driver has DT support, drop old style configuration of it and add DT in its place. Since all the boards enable the EHCI, enable it by default in kirkwood.dtsi. Any new boards which don't have USB can specifically disable it. Signed-off-by: Andrew Lunn and...@lunn.ch --- arch

EHCI: Centralize controller initialization

Hi Alan kisskb is showing up a warning in drivers/usb/host/ehci-orion.c which i think is from a change you made: drivers/usb/host/ehci-orion.c:109:2: warning: passing argument 1 of 'ehci_setup' from incompatible pointer type [enabled by default] diff --git a/drivers/usb/host/ehci-orion.c